Subject: route objects in RPSL

From: Mark Prior <[email-masked]>
Date: Tue, 12 Oct 1999 18:02:12 +0930

Now that Merit have implemented against the RPSL spec I discovered
that the route objects have grown attributes that I hadn't noticed in
all those sessions with the drafts (both v1 and v2). These attributes
(admin-c and tech-c) doesn't make the transformation from RIPE 181 to
RPSL as straight forward as I had expected as they are mandatory and
thus hard to avoid, although David Kessens' server doesn't even
recognise them since I assume like me he didn't notice them creep into
the standard.

I would like to test other people's feelings about their appearance,
especially as mandatory attributes.

Did other people notice them, or was I alone :-) and if not should
they be there (mandatory or not).

Comments?

Mark.

---

From: David Kessens <[email-masked]>
Date: Tue, 12 Oct 1999 18:13:07 -0600

Mark,

> they be there (mandatory or not).

They should not be there if you follow the RIPE specs which are the
specs that most people claim to follow:

from the draft:
> 3 Contact Information
> 
> The mntner, person and role classes, admin-c, tech-c, mnt-by, changed,
> and source attributes of all classes describe contact information. The
> mntner class also specifies authenticaiton information required to
> create, delete and update other objects. These classes do not specify
> routing policies and each registry may have different or additional
> requirements on them. Here we present the common denominator for
> completeness which is the RIPE database implementation [17]. Please
> consult your routing registry for the latest specification of these
> classes and attributes. The ``Routing Policy System Security''
> document [21] describes the authenticaiton and authorization model in
> more detail.

At the same time, if you follow the recommendations for how to write
tools that interact with the routing registry, it is advised to only
look for the attributes that you need, and to ignore all others. This
practice will make sure that your tools will not stop working if
extensions (attributes) are added later on in time.

David K.
---

---

From: <[email-masked]>
Date: Fri, 15 Oct 1999 13:33:48 -0700 (PDT)

Mark,

The spec says 3 things:
1) admin-c is optional, tech-c is mandatory for route objects
2) this is the ripe db behavior
3) rpsl spec is not authoritative over the contact information 

Obviously the spec is wrong about (2) as you brought out the tech-c
issue. It seems like so many of us missed this.

Because spec says (2) and (3), we should fix (1) to be consistent with
the ripe behavior. Because of (3), we can change this behavior today
in our implementations and make the rpsl spec consistent when we edit
it for DS.

Is this agreeable to everyone? 

Thanks.

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California

---

From: Joao Luis Silva Damas <[email-masked]>
Date: Mon, 18 Oct 1999 15:16:18 +0200

>Is this agreeable to everyone?

Why not? This was not overlooked, just assumed this is what people wanted
since this has been on the draft for a very long time. We just programmed
it and it's easy enough to get rid of it.
We have a community buy in to support the whole of rpsl (and part of
rps-auth), and that, of course, implies some changes. This would just be
one of them.

I must say though, that I missed the part of the draft where it sayed that
rpsl is not authoritative over

Cheers,
Joao

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Mon, 18 Oct 1999 09:04:35 -0700 (PDT)

> rpsl is not authoritative over

The mntner, person and role classes, admin-c, tech-c, mnt-by, changed, and
source attributes ...  These classes do not specify routing policies and
each registry may have different or additional requirements on them.  Here
we present the common denominator for completeness which is the RIPE
database implementation [17].  Please consult your routing registry for the
latest specification of these classes and attributes.

Cengiz