Implementation practices

### On Tue, 8 Oct 2002 19:15:34 -0400, "Jason Lixfeld"
### <> casually decided to expound upon
### <> the following thoughts about "Implementation
### practices":

Irrd-discuss didn't have anything at all to say about this, so I thought
I'd bring it here for a different, practical perspective.

Hmm... apparently I'm not allowed to post to irrd-discuss since I'm not a
member. I'm getting mail through group-wide exploder. Rather than wait for
me to be added I thought I'd send a reply to this one.

I'd like to think that the former is true :slight_smile: so if that's the case, what
are some of the best practices? Is it just as simple as creating a
database which RADB mirrors, containing general maintainer, as and route
objects then having a private, un-mirrored/non-exported database
containing all the nuts and bolts which you run ratoolset (or other,
home made widget) against?

This brings to mind a proposal I made many years ago while at a previous
employ. We saw the need to maintain both public and private data and one
thought was to extend the RPSL spec to do it. We were also attempting to
modify IRRd to support this. I know this is not quickly implimentable nor a
BCP and I'm not sure anyone would still be interested but I thought I'd
throw it out again.

Basically, add two optional attributes to each object. These will be
local-acl and access-by. Here is an example aut-num object with the

  aut-num: AS3549
  as-in: AS3967 10 AS-EXODUS AND NOT {}
  as-out: AS3967 AS-GLOBALCENTER
  local-acl: as-in(FGCSTAFF+rw),
      as-out(FGCSTAFF+rw, EXODUS+r)
        access-by: ACCESS-FGCSTAFF

In addition, all people/objects referenced in the maint-by: field
should probably have explicit +rw access.

All fields should probably have implicit ALL+r associated with them,

I guess the regex format for the local-acl: object would be

or the like.

The local-acl attribute is a local override to the access object which I
will describe below. The access-by references the access object from within
the controlled object.

Although I have not fully fleshed out the access object, here are the key

  acl: aut-num(ALL+r), mnt-by(ALL+r)
  acl: as-in(ALL-rw), as-out(ALL-rw)
  acl: ALL(ALL-rw), access(FGCSTAFF+rw)
  local-acl: acl(FGCSTAFF+rw)
  mnt-by: MAINT-AS3549

The syntax of the local-acl and acl atribute is as follows:

  local-acl | acl: attribute(ACLGROUP operator perm)

ACLGROUP will reference another object which defines the entity of the
access and can define method as well as criteria. The operator is either a
+ or - that permits or denies the permission which is either r or w for read
or write. Note that referencing a primary key attribute in an acl or
local-acl attribute will cause any attributes of that object type to inherit
the permissions of the primary key attribute unless explicitly defined by
another acl or local-acl.

The aclgroup can define a single person or group of
persons/networks/hosts/etc. We haven't fully fleshed this out either but
I'm envisioning something like this:

  aclgroup: FGCSTAFF
  acl-permit: 206.251.8/24
The first acl-permit specifies a user@host. The second specifies individual
host control. The third is a network access description. The fourth
describes domain access. And the acl-deny is an example of how to deny
based on domain.