With all due respect to everyone concerned, there's no way an end user
or IT department can buy a bunch of machines based on the text currently
contained in this proposed Standard Track document and
1) be able to predict how each machine will behave by defaultin advance
of actually plugging it in.
2) be able to effectively manage a machine's behaviour remotely via an
IETF defined control mechanism, because the various MAYs and SHOULDs
cannot be overridden by the two things that are actually reasonably well
defined by the IETF i.e.
the prefix policy table + draft-ietf-6man-addr-select-opt-03 for
transporting that policy table.
That suggests to me that we're not yet completely on the right track.
IMHO If there's an implementation option in 3484bis, there should always
be a corresponding control option in the (prefix) policy table, plus a
way to effectively transport that policy table in e.g.
draft-ietf-6man-addr-select-opt-03.
Align and package all 3 together, and you have a far better solution.
regards,
RayH
Dave Thaler wrote:
Brian Carpenter writes:
> > The wording I propose to add is:
> >
> > "There SHOULD be an administrative option to change this preference, if the
> > implementation supports privacy addresses. If there is no such
option, there
> > MUST be an administrative option to disable privacy addresses."
> >
> > -Dave
>
> That works for me. Perhaps there also needs to be a general statement in the
security
> considerations that all administrative changes and options MUST be secured
against illicit use.
Done. Draft-02 now includes the wording above, and adds a general statement
in the
security considerations section as you suggested.
-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
