North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Using RPSL in real life with the IRR's

  • From: gerald
  • Date: Mon Jun 26 10:01:18 2000

> My real question is:  Can anyone point me to a policy(s) that use more =
> than the general import/export policies such as import: from AS#### =
> action pref=3D100; accept AS#### (or usually ANY) AND NOT {}, =
> etc, etc, etc.

Try AS2764 (courtesy of Mark Prior from

> If I have interpreted RFC-2622 correctly for what the language can do it =
> seems that many of the problems in the discussion 'using IRR tools for =
> BGP route filtering' would be under much tighter policy control.  Of =
> course if the IRR databases were more up to date, many of the queries I =
> made had dates that said they had not been changed since 1994.

There has been much debate over the 'changed:' attribute at the ripe
meetings.  The problem being the field is not auto-generated but
relies on the user to put in a value.  The software only checks to 
dissallow dates in the future (much to the detriment of our friends
on the other side of the international date line).  To overcome
the date line problem and to encourage users to let the software
insert a date you can omit the date and the software will auto-generate
it for you.

So because the 'changed:' attribute is usually supplied by the
submitter it many times is not changed.  And thus you cannot really
assume anything regarding the last date of modification.  Sometimes a 
stale date is really stale and other times it is not.  

The result of the debate over this field at the ripe meetings was
to leave the field alone, mainly because no agreement could be reached.
Many people felt the field would be a breach of privacy if the field
were auto-generated.  There is also a group of people who wanted to 
see the attribute go away entirely.  I personally would like to see the 
field auto-generated but at this time there are no plans to change it.  

BTW, you can use us ([email protected]) as a resource for RPSL syntax 
and policy questions.  There is also a mailing list [email protected]