[Opendnssec-develop] Re: Our little get-together. Re: Progressing OpenDNSSEC.

[Roy Arends]

Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 11/15/2008 04:51:51 PM:

> >> - During the meeting I referred to the 'vapor ware' that we call
> >> Masterdont. The core of this idea is that we have a kernel that is
> >> aware of all possible interactions with, properties off, and 
> >> relations
> >> of the environments with zone.
> >>
> >> In that context I think it is important to make the zone I/O
> >> intelligence and the KASP language extendible so that KASP is to
> >> become a subset of a zone-policy language that not only describes the
> >> signing and key properties of zones but can also describe TTL,
> >> Nameserver, and content properties for zones.
> >
> > KASP was specifically designed with DNSSEC in mind, and deals with the
> > various timings, state and properties of keys. I think what you are
> > referring to is the ability to contain KASP in NSCP. I think that 
> > generic
> > configuration items should go into NSCP, and that various state 
> > properties
> > of keys should remain in KASP.
> 
> That is not exactly what I refer to.
> 
> A zone can have many properties, such as the policy it is signed with, 
> which keys are used to implement that policy, which nameservers it is 
> served on, which clients are allowed to query it, its SOA timing 
> prarameters, etc, etc. Some of these properties are expressed in the 
> language that KASP will use for its configuration, others will be used 
> in NSCP.

Yes.

> If you are starting on a framework to maintain a subset of properties 
> for zones, which I think KASP is, then you better make sure you can 
> add the other pieces too. Make it extendable: while not solving all of 
> ones problems at once make sure you can in the future build upon the 
> foundations you are setting.

Okay. Lets go over this face to face next week. I think we're in 
agreement, though we might not be convinced ;-)

> >> I have asked Matthijs to set up requirements for this (based on KASP
> >> and NSCP) and come up with an architecuture of what I refer to as the
> >> "Masterdont kernel". Although work on phase 1 of the project is to
> >> large extend orthogonal to this idea there are a few hooks, 
> >> specifically
> >
> >> - Colleagues from SURFNET are interested in working along and even
> >> providing resources in the form of a programmer. I am not sure if
> >> there is need for adding  resources to phase 1 of the project (and if
> >> we do if there is efficiency gain). But I think they should be privy
> >> to the requirements document.
> >
> > I think that we have covered most (all) bases with the current team. I
> > have no problem adding development resources if there is a yet
> > unidentified part of this project. However, I'm not convinced we more
> > resources. However, since SURFNET host a large amount of zones, I 
> > can see
> > value in inviting them to test the software.
> 
> I think that might be rather late. Why not use them as a sounding 
> board for assessing if your current set of requirements and your 
> vision would work for them?

That is a good idea. Could you elaborate on who is your point of contact 
within SURFNET?

Thanks,

Roy