Re: RE: 3484bis and privacy addresses

[Ray Hunter <[e-mail]>]

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