On Fri, 2011-09-23 at 10:46 -0400, Adam Young wrote:
> On 09/23/2011 02:02 AM, Martin Kosek wrote:
> > On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
> >> On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
> >>>> OPEN QUESTION: should we implement these new commands also for discrete
> >>>> DNS records types to be consistent? I mean for example A, AAAA, CNAME,
> >>>> PTR, ... They would look like
> >>>>
> >>>>> ipa dnsrecord-aaaa-add --ip-address=IPAddress
> >>>> BENEFITS of this approach (command per RR type):
> >>>> - use can get all help for RR type by simply typing "ipa help
> >>>> dnsrecord-mx-add"
> >>>> - we would be able to implement helper methods consistently on one
> >>>> place, for example:
> >>>> dnsrecord-aaaa-add --from-mac=00:1D:BA:06:37:64
> >>> If we have this for all record types the UI can use a generic code to
> >>> figure out which command to use. Everything will be in this pattern:
> >>> dnsrecord-<rrtype>-add/mod/del<primary keys>  [parameters*]
> >> We won't have it for all types, so we will need a map.  Most  will use
> >> the old API, and a few will use the pattern above
> > I think to make this all as consistent as possible, new API shall be
> > implemented for all types (except unsupported and DNSSEC ones). Rob did
> > agree with this approach too.
> >
> > Martin
> >
> Lets proceed with caution here.  I think we can really complicate things 
> with this approach.

Ok, lets see...

>  From a UI perspective, we will have to tailor the  control to be used 
> for any DNS record type that gets more than a single field.
>  From what I've seen, and the types we have to deal with thus far, only 
> the SRV and MX records  are really used that much.  Lets implement for 
> them  first and test it out.
> For certificate based records,  DNS and otherwise, we want to get file 
> upload working, as cut and paste etc is a PITA.  I'm not sure if we 
> really need the Cert based records, but I suspect that, from a Dogtag 
> perspective, there is a lot of things we could do with a tight 
> integration of the two.  I can even see an API where we generate a Cert 
> based record  from a Certificate Signing Request.

That's the benefit of command-per-type approach. We could implement some
helpers to dnsrecord-cert-add when file upload is ready or we specify a
way to cooperate with dogtag there.

> For A  and AAAA records, we don't need a new API, we need a pattern.  
> For A record  that pattern is:
> \b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b
> For AAAA records that is:
> /^\s*((([0-9A-Fa-f]{1,4}:){7}([0-9A-Fa-f]{1,4}|:))|(([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}|((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){5}(((:[0-9A-Fa-f]{1,4}){1,2})|:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){4}(((:[0-9A-Fa-f]{1,4}){1,3})|((:[0-9A-Fa-f]{1,4})?:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){3}(((:[0-9A-Fa-f]{1,4}){1,4})|((:[0-9A-Fa-f]{1,4}){0,2}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){2}(((:[0-9A-Fa-f]{1,4}){1,5})|((:[0-9A-Fa-f]{1,4}){0,3}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){1}(((:[0-9A-Fa-f]{1,4}){1,6})|((:[0-9A-Fa-f]{1,4}){0,4}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(:(((:[0-9A-Fa-f]{1,4}){1,7})|((:[0-9A-Fa-f]{1,4}){0,5!
> Yep, they are nasty.  But that is going to be the case regardless of 
> whether we use the new API or not.

I agree - that's not pretty. On the server side, I would like to use
services of python-netaddr package. This package is able to validate
both A or AAAA records. I don't see the benefit of using own regex

> Lets deal with these issues, and hold  the API explosion  until later.


Freeipa-devel mailing list

Reply via email to