Subject: Question about hierarchical names and authentication

From: Mark Prior <[email-masked]>
Date: Wed, 15 Jul 1998 23:19:44 +0930

This may be an implementation issue or a language issue so I thought I
would raise it here.

When using hierarchical set names in order to create an object such as
AS2764:AS-GLOBAL there needs to be an AS2764 object and you need to
use the authentication mechanism associated with it's maintainer. This
is fairly clear but what happens when you want to use more levels? In
particular where the intermediate levels are aut-num names?

If I am AS2764 and I have a peer AS1221 and I want to create two sets
associated with the relationship, say AS2764:AS1221:AS-TRANSIT and
AS2764:AS1221:AS-END, would I need to create AS2764:AS1221 even though
it's not necessary for my application? If it is currently necessary
should it be?

Why would I want to do this?

I could have a set of peers and want to apply the same basic policy to
the import of routes from each of them, although specific to each of
them. Rather than iterate them all I could make use of PeerAS with the
following:

import: from AS2764:AS-PEERS
        accept <^PeerAS+ AS2764:PeerAS:AS-TRANSIT* AS2764:PeerAS:AS-END~*$>

Note I lifted this policy fragment from Telstra's policy at their RPSL
based registry (although they didn't specify it this way :-)

Mark.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Wed, 15 Jul 1998 08:50:51 -0700

> it's not necessary for my application? If it is currently necessary

You can not create AS2764:AS1221 since it is not a valid as-set name. You
could use:
	AS2764:AS-TRANSIT:AS1221
	AS2764:AS-END:AS1221
and you will need to create:
	AS2764:AS-TRANSIT	and
	AS2764:AS-END
(only once for all, not once per peer).

You are right, even though you do not need AS2764:AS-TRANSIT and
AS2764:AS-END, you will have to create them. But their number is fixed and
hopefully small, whereas the number of AS2764:ASx you may have is not
fixed and growing...

>         accept <^PeerAS+ AS2764:PeerAS:AS-TRANSIT* AS2764:PeerAS:AS-END~*$>

<^PeerAS+ AS2764:AS-TRANSIT:PeerAS* AS2764:AS-END:PeerAS~*$>

---

From: Mark Prior <[email-masked]>
Date: Thu, 16 Jul 1998 09:18:36 +0930

Well David's server is erroneous then since it allowed me to do it!
Also the text of RFC 2280 would need to be changed since it doesn't
disallow it either. The text says '[a] hierarchical set name is a
sequence of set names and AS numbers separated by colons ":".' It
doesn't say the final component must be a set name!

It seems a trifle redundant don't you think?

You going to add that to your RtConfig test cases? :-)

Mark.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 16 Jul 1998 10:10:41 -0700

> doesn't say the final component must be a set name!

One component has to be a set name. I just fixed the spec.

> It seems a trifle redundant don't you think?

What is the alternative?

> You going to add that to your RtConfig test cases? :-)

no problem.

---

From: Mark Prior <[email-masked]>
Date: Fri, 17 Jul 1998 09:13:58 +0930

What is the alternative?

I would have suggested that it work itself back up the list so if you
are trying to create
        AS2764:AS1221:AS-SET

then it looks for an object called AS2764:AS1221. If it finds it then
it uses its authentication info otherwise it strips the next
component and tries AS2764. If that succeeds then it uses its
authentication info otherwise it strips again. This returns a 0 lenth
label so authentication fails.

Mark.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Fri, 17 Jul 1998 11:08:56 -0700

Mark Prior on Fri, 17 Jul 1998 09:13:58 +0930 said:
>      >      AS2764:AS-END, you will have to create them. But their number is 
fixed a
>      nd

Good idea. It would be nice if the same rule applied equally to flat names
(i.e. as-foo).

Cengiz