RE: RE: 3484bis and privacy addresses

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Ray Hunter [mailto:[e-mail]]
> Sent: Wednesday, April 11, 2012 6:51 AM
> To: Dave Thaler
> Cc: Brian E Carpenter; [e-mail]
> 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
>