> -----Original Message----- > From: Ray Hunter [mailto:[email protected]] > Sent: Wednesday, April 11, 2012 6:51 AM > To: Dave Thaler > Cc: Brian E Carpenter; [email protected] > Subject: Re: RE: 3484bis and privacy addresses > > 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.
I don't follow. Can you provide a specific example of something you are concerned about? > > 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. No, the prefix policy table is for configuring a specific subset of rules (the ones using labels and preference). Configurability for other rules isn't part of the "prefix policy table", but is still configurable. -Dave > > 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 --------------------------------------------------------------------
