On Thu, 18 Sep 2014 14:22:07 -0400
Nathaniel McCallum <npmccal...@redhat.com> wrote:

> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote:
> > On Thu, 18 Sep 2014 13:56:44 -0400
> > Nathaniel McCallum <npmccal...@redhat.com> wrote:
> > 
> > > -objectClasses:  (2.16.840.1.113730.3.8.16.2.2  NAME
> > > 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type'
> > > MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $
> > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY
> > > (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses:
> > > (2.16.840.1.113730.3.8.16.2.2  NAME 'ipatokenTOTP' SUP ipaToken
> > > STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $
> > > ipatokenOTPalgorithm $ ipatokenOTPdigits $
> > > ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $
> > > ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP')
> > 
> > NACK, you cannot move from MAY to MUST.
> 
> This is precisely what we have been discussing on IRC today. The
> consensus was that this was acceptable because of the update plugin
> and the rarity of the state in which a token would not have
> ipatokenTOTPwatermark set (the token has to be created an never used).

Sorry I was not around, but it is never acceptable, as it may cause
replication failures.

This has been a long (albeit perhaps unspoken) rule in changing schema
in FreeIPA.

Existing objectlasses can *never* gain new MUST attributes. This rule
is rigid and is non-negotiable.

Sorry.
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to