OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [kmip] Groups - CryptoParamsEnforcement uploaded


Just to make it abundantly clear - this proposal is suggesting text
which directly conflicts with an already accepted and balloted item
which has been included in the specification working drafts. It also
conflicts with the stated way things are handled within KMIP for
Cryptographic Parameters and attempts to enforce a behaviour which
conflicts with the specification text and the usage guide for all
existing versions of KMIP.

It also fundamentally changes the purpose of Cryptographic Parameters
within the specification.

If any other vendor feels that we need to change direction on this then
they need to speak up (a request which has been repeated multiple times
over the last 11 months that John has been suggesting that we need to
change how Cryptographic Parameters are handled). I don't believe there
is any support for such a proposal within the TC (I've received no
indication of such either on or off the list and substantial
confirmation off list that this suggested change is simply not supported).

If there are other vendors who wish to support this proposal from John
then we will respond with a detailed critique of the errors within that
proposal - but otherwise we will simply continue to assume that there is
no support for John's regularly repeated request for a change of
direction on this topic.

We have discussed this topic at length multiple times, and continuing to
raise the same issue which has already been discussed and a balloted and
incorporated in the specification absent strong multiple vendor support
seems very much at odds with the process we have been following for
decision making. We don't always agree on topics - but once a decision
has been made for a given version it takes pretty extraordinary
circumstances and clear multi-vendor support to change direction for a
given release.

We also have a clear mechanism defined for handling behaviours that are
not something that fit within the base specification - and that is one
of profiles - and that is the right way to address suggestions for
mandatory behaviour enforcement that are not supported by the TC for
being in the specification.

Thanks,
Tim.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]