KFW releases off the trunk will become harder as 1.7 features start getting used

[Jeffrey Altman]

NIM2 is not dependent upon 1.7.  However, given the recent discussions of
the new credential cache not supporting CCAPIv2 there will be a break in
functionality of NIM and NIM2 if the new CCAPI is deployed without 
re-writing
the NIM Kerberos v5 provider.  (Also note that the KFW klist.exe is also
dependent upon CCAPIv2.)

As long as the 1.7 libraries do not break backward compatibility, there is
no issue for NIM2 (and other applications that depend on MIT Kerberos.)
If there is a break in backward compatibility, it will be harder to deploy
a new krb5 NIM provider that supports both the old and the new libraries.

Jeffrey Altman
Secure Endpoints Inc.


Kevin Koch wrote:
> Jeff --
>
> Considering the later discussion of NIM2 being independent of the Kerberos
> 1.7 libraries, is 1.7 a non-issue for NIM2?
>
> Thanks.
>
> Kevin 
>
>> -----Original Message-----
>> From: kfwdev-bounces at MIT.EDU [mailto:kfwdev-bounces at MIT.EDU] On Behalf Of
>> Sam Hartman
>> Sent: Monday, November 12, 2007 5:43 PM
>> To: kfwdev at mit.edu
>> Subject: KFW releases off the trunk will become harder as 1.7 features
>> startgetting used
>>
>> One long-running aspect of our release process is that the trunk is
>> allowed to take advantage of features on the trunk.  In particular
>> this means things like as we get new implementations of CCAPI, KIM and
>> other APIs available, we'll want to start using them.  And we don't
>> generally support backward compatibility for this sort of change.
>>
>> One consequence of this is that we may start running into cases where
>> specific changes to KFW will end up depending on the 1.7 release or
>> at least the 1.7 release branch.  I'd expect to get to a point in a
>> few months where any significant changes to KFW would depend on 1.7.
>>
>> We've been traditionally very reluctant to pull significant features
>> for future releases back to old release branches.  I'd expect Tom to
>> continue that practice.  We may develop more well defined guidelines
>> for when pull-ups are appropriate, but I would expect anything we came
>> to consensus on to be relatively conservative in this regard.
>>
>> There may be projects that we want to consider and try and avoid
>> blocking behind 1.7.  I think that quite soon, we're going to want to
>> establish a deadline for any such project to be proposed and for us to
>> at least have the community discussion about whether we want to avoid
>> blocking the projects behind 1.7.
>>
>> Kevin, I'd appreciate it if you could work with Jeff and anyone else
>> who has an opinion and decide on a deadline by which projects that
>> want to avoid being blocked behind 1.7 must be proposed.
>>
>> I think that shorter than two weeks from today would be unrealistic.
>> I think that a deadline beyond Jan 15 would probably be too long.
>>
>>
>> One specific concern I have is the NIM 2.0 work.  There was a project
>> proposal over the summer for the user experience.  However there
>> hasn't been any proposals made regarding technical impact or how the
>> user experience would be accomplished.
>>
>> That's fine, but until such proposals are reviewed, we as a group
>> won't be in a position to avoid taking NIM 2.0 design into account and
>> avoid making things harder for NIM 2.0.
>>
>> Thanks for your consideration
>>
>> --Sam
> ...
>
> _______________________________________________
> kfwdev mailing list
> kfwdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kfwdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20080206/4d80022c/attachment.bin