<!DOCTYPE rpsl_syntax SYSTEM "syntax.dtd">

<!-- 

file: syntax.xml

description: Defines the various syntaxes that RPSL attributes can have.

$Id: syntax.xml,v 1.14 2002/02/05 12:56:20 shane Exp $

-->

<rpsl_syntax>

   <attribute_syntax name="filter-set">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
          <regex>
              ^fltr-[A-Z0-9_-]*[A-Z0-9]$
          </regex>
       </front_end>
       <description>
     An filter-set name is made up of letters, digits, the
     character underscore "_", and the character hyphen "-"; it
     must start with "fltr-", and the last character of a name
     must be a letter or a digit.
       </description>
   </attribute_syntax>

   <attribute_syntax name="irt">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
          <regex>
              ^irt-[A-Z0-9_-]*[A-Z0-9]$
          </regex>
       </front_end>
       <description>
     An irt name is made up of letters, digits, the character
     underscore "_", and the character hyphen "-"; it must start
     with "irt-", and the last character of a name must be a
     letter or a digit.
       </description>
   </attribute_syntax>

   <attribute_syntax name="as-set">
       <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
           <regex>
              ^((AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|as-[A-Z0-9_-]*[A-Z0-9]):)*as-[A-Z0-9_-]*[A-Z0-9](:(AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|as-[A-Z0-9_-]*[A-Z0-9]))*$
           </regex>
       </front_end>
       <description>
     An route-set name is made up of letters, digits, the
     character underscore "_", and the character hyphen "-"; it
     must start with "as-", and the last character of a name must
     be a letter or a digit.

     An as-set name can also be hierarchical.  A heirarchical set
     name is a sequence of set names and AS numbers separated by
     colons ":".  At least one component of such a name must be
     an actual set name (i.e. start with "as-").  All the set
     name components of a heirarchical route-name have to be
     route-set names.
       </description>
   </attribute_syntax>

   <attribute_syntax name="route-set">
       <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
           <regex>
              ^((AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|rs-[A-Z0-9_-]*[A-Z0-9]):)*rs-[A-Z0-9_-]*[A-Z0-9](:(AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|rs-[A-Z0-9_-]*[A-Z0-9]))*$
           </regex>
       </front_end>
       <description>
     An route-set name is made up of letters, digits, the
     character underscore "_", and the character hyphen "-"; it
     must start with "rs-", and the last character of a name must
     be a letter or a digit.

     A route-set name can also be hierarchical.  A heirarchical
     set name is a sequence of set names and AS numbers separated
     by colons ":".  At least one component of such a name must
     be an actual set name (i.e. start with "rs-").  All the set
     name components of a heirarchical route-name have to be
     route-set names.
       </description>
   </attribute_syntax>

   <attribute_syntax name="peering-set">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
          <regex>
              ^prng-[A-Z0-9_-]*[A-Z0-9]$
          </regex>
       </front_end>
       <description>
     A peering-set name is made up of letters, digits, the
     character underscore "_", and the character hyphen "-"; it
     must start with "prng-", and the last character of a name
     must be a letter or a digit.
       </description>
   </attribute_syntax>

   <attribute_syntax name="rtr-set">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
          <regex>
              ^rtrs-[A-Z0-9_-]*[A-Z0-9]$
          </regex>
       </front_end>
       <description>
     A router-set name is made up of letters, digits, the
     character underscore "_", and the character hyphen "-"; it
     must start with "rtrs-", and the last character of a name
     must be a letter or a digit.
       </description>
   </attribute_syntax>

   <attribute_syntax name="members-as">
       <front_end>
          <regex>
^((((AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|as-[A-Z0-9_-]*[A-Z0-9]):)*as-[A-Z0-9_-]*[A-Z0-9](:(AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5])|as-[A-Z0-9_-]*[A-Z0-9]))*)|AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-5]))$
          </regex>
       </front_end>
       <description>
     &lt;as-number&gt; or
     &lt;as-set-name&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="members-is">
       <front_end>
           <parser_name>members_is</parser_name>
       </front_end>
       <description>
     &lt;inet-rtr-name&gt; or
     &lt;rtr-set-name&gt; or
     &lt;ipv4-address&gt;
       </description>
   </attribute_syntax>


   <attribute_syntax name="members-rs">
       <front_end>
          <parser_name>members_rs</parser_name>
       </front_end>
       <description>
     &lt;address-prefix-range&gt; or
     &lt;route-set-name&gt; or
     &lt;route-set-name&gt;&lt;range-operator&gt;.
       </description>
   </attribute_syntax>

   <attribute_syntax name="mbrs-by-ref">
       <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
           <regex>
               ^[A-Z]([A-Z0-9_-]*[A-Z0-9])?$
           </regex>
           <!-- note that ANY is not reserved for mbrs-by-ref -->
           <reserved_regex>
               ^(as-any|rs-any|peeras|and|or|not|atomic|from|to|at|action|accept|announce|except|refine|networks|into|inbound|outbound|rs-.*|rtrs-.*|fltr-.*|prng-.*)$
           </reserved_regex>
       </front_end>
       <description>
     &lt;mntner-name&gt; | ANY 
       </description>
   </attribute_syntax>
   
   <attribute_syntax name="free-form">
       <description>
     A sequence of ASCII characters.
       </description>
   </attribute_syntax>

   
   <attribute_syntax name="nic-handle">
       <core>
          <regex>
              ^.{1,30}$
          </regex>
       </core>
       <front_end>
           <regex>
             ^([A-Z]{2,4}[0-9]{0,6}(-[A-Z]{1,9})?|(AUTO-[0-9]+([A-Z]{2,4})?(-[A-Z]{2,4})?))$
           </regex>
       </front_end>
       <description>
     From 2 to 4 characters optionally followed by up to 5 digits
     optionally followed by a source specification.  Source
     specification starts with "-" followed by source name up to
     9-character length.
       </description>
   </attribute_syntax>
   
   <attribute_syntax name="object-name">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
      </core>    
      <front_end>
           <regex>
               ^[A-Z]([A-Z0-9_-]*[A-Z0-9])?$
           </regex>
           <reserved_regex>
               ^(any|as-any|rs-any|peeras|and|or|not|atomic|from|to|at|action|accept|announce|except|refine|networks|into|inbound|outbound|as-.*|rs-.*|rtrs-.*|fltr-.*|prng-.*|irt-.*)$
           </reserved_regex>
       </front_end>
       <description>
     Made up of letters, digits, the character underscore "_",
     and the character hyphen "-"; the first character of a name
     must be a letter, and the last character of a name must be a
     letter or a digit.  The following words are reserved by
     RPSL, and they can not be used as names:
   
      any as-any rs-any peeras and or not atomic from to at
      action accept announce except refine networks into inbound
      outbound
   
     Names starting with certain prefixes are reserved for
     certain object types.  Names starting with "as-" are
     reserved for as set names.  Names starting with "rs-" are
     reserved for route set names.  Names starting with "rtrs-"
     are reserved for router set names. Names starting with
     "fltr-" are reserved for filter set names. Names starting
     with "prng-" are reserved for peering set names. Names
     starting with "irt-" are reserved for irt names.
       </description>
   </attribute_syntax>

   <attribute_syntax name="netname">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
      </core>    
      <front_end>
           <regex>
               ^[A-Z]([A-Z0-9_-]*[A-Z0-9])?$
           </regex>
       </front_end>
       <description>
     Made up of letters, digits, the character underscore "_",
     and the character hyphen "-"; the first character of a name
     must be a letter, and the last character of a name must be a
     letter or a digit.
       </description>
   </attribute_syntax>
   
   <attribute_syntax name="e-mail">
       <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>   
       <front_end>
           <regex>
               ^(([^][()&lt;&gt;,;:\\&quot;[:space:]]+)|(&quot;[^&quot;@\\]+&quot;))@([A-Z0-9-]+(\.[A-Z0-9-]+)+)$
           </regex>
       </front_end>
       <description>
     An e-mail address as defined in RFC 2822.
       </description>
   </attribute_syntax>
   
   <!-- XXX:
      The changed attribute now treats the date as optional.  This
      should probably be modified so that dates are required, but
      only issue a warning.
     -->
   <attribute_syntax name="changed">
       <front_end>
           <regex>
               ^(([^][()&lt;&gt;,;:\\&quot;[:space:]]+)|(&quot;[^&quot;@\\]+&quot;))@([A-Z0-9-]+(\.[A-Z0-9-]+)+)( [0-9]{8})?$
           </regex>
       </front_end>
       <description>
     An e-mail address as defined in RFC 2822, followed by a date
     in the format YYYYMMDD.
       </description>
   </attribute_syntax>
   
   <attribute_syntax name="filter">
       <front_end>
         <parser_name>filter</parser_name>
       </front_end>
       <description>
     Logical expression which when applied to a set of routes
     returns a subset of these routes. Please refer to RFC 2622
     for more information.
       </description>
   </attribute_syntax>

   <attribute_syntax name="registry-name">
       <front_end>
           <regex>^[A-Z]+$</regex>
       </front_end>
       <description>
     Uppercase text.
       </description>
   </attribute_syntax>

   <attribute_syntax name="domain-name">
       <core>
          <regex>
              ^.{1,254}$
          </regex>
       </core>   
       <front_end>
           <regex>
               ^[A-Z0-9]([-A-Z0-9]*[A-Z0-9])?(\.[A-Z0-9]([-A-Z0-9]*[A-Z0-9])?)*$
           </regex>
       </front_end>
       <description>
     Domain name as specified in RFC 1034 without trailing dot
     (".").  The total length should not exceed 254 characters
     (octets).
       </description>
   </attribute_syntax>

   <!-- used in cases where we want any allowable character -->
   <attribute_syntax name="subdomain-name">
       <core>
          <regex>
              ^.{1,254}$
          </regex>
       </core>   
       <front_end>
           <regex>
               [A-Z0-9]([-A-Z0-9]*[A-Z0-9])?(\.[A-Z0-9]([-A-Z0-9]*[A-Z0-9])?)*$
           </regex>
       </front_end>
       <description>
     Domain name as specified in RFC 1034 without trailing dot
     (".").  The total length should not exceed 254 characters
     (octets).
       </description>
   </attribute_syntax>

   <attribute_syntax name="ipv4-address">
       <front_end>
           <regex>
           ^(([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$
           </regex>
       </front_end>
       <description>
     An IPv4 address is represented as a sequence of four
     integers in the range from 0 to 255 separated by the
     character dot (".").  For example, 128.9.128.5 represents a
     valid IPv4 address.
       </description>
   </attribute_syntax>

   <attribute_syntax name="refer">
       <core>
           <parser_name>refer</parser_name>
       </core>
       <description>
     &lt;type&gt; &lt;hostname&gt; [&lt;port&gt;]

     &lt;type&gt;  specifies the type of referral to be used.
     Supported types are SIMPLE, INTERNIC, RIPE, and
     CLIENTADDRESS.

     &lt;hostname&gt;  is the DNS name or &lt;ipv4 address&gt; of
     the referred host.

     &lt;port&gt;  is an integer specifying TCP port number at
     which queries are accepted by the referred host.  If
     &lt;port&gt; is omitted, the default number of 43 is used.
       </description>
   </attribute_syntax>

   <attribute_syntax name="person-name">
       <core>
          <regex>
          <!-- Not more than 10 words <64 char each --> 
          <!-- we allow \ in order to allow MySQL escaped strings to pass -->
              ^[A-Z0-9.\\`'_-]{1,64}( [A-Z0-9.\\`'_-]{1,64}){0,9}$
          </regex>
       </core>   
       <front_end>
           <regex>
               ^[A-Z0-9]([A-Z0-9.`'_-]*[A-Z0-9`'_-])?([[:space:]]+[A-Z0-9.`'_-]+)*[[:space:]]+[A-Z0-9]([A-Z0-9.`'_-]*[A-Z0-9`'_-])?$
           </regex>
           <reserved_regex>
               (^(Dr|Prof|Mv|Ms|Mr)\.?[[:space:]])|([[:space:]](Dr|Prof|Mv|Ms|Mr)\.?[[:space:]])
           </reserved_regex>
       </front_end>
       <description>
     A list of at least 2 words separated by white space. The
     first and the last word cannot end with dot ("."). The
     following words are not allowed: "Dr", "Prof", "Mv", "Ms",
     "Mr", no matter whether they end with dot (".") or not. A
     word is made up of letters, digits, the character underscore
     "_", and the character hyphen "-"; the first character of a
     name must be a letter, and the last character of a name must
     be a letter or a digit.
       </description>
   </attribute_syntax>

   <attribute_syntax name="telephone-number">
       <front_end>
           <regex>
               ^\+[[:space:]]*[0-9][0-9.[:space:]-]*(\([0-9.[:space:]-]*[0-9][0-9.[:space:]-]*\))?([0-9.[:space:]-]*[0-9][0-9.[:space:]-]*)?([[:space:]]+ext.[0-9.[:space:]-]*[0-9][0-9.[:space:]-]*)?$
           </regex>
       </front_end>
       <description>
     Contact telephone number. Can take one of the forms:

     '+' &lt;integer-list&gt;
     '+' &lt;integer-list&gt; "(" &lt;integer-list&gt; ")" &lt;integer-list&gt;
     '+' &lt;integer-list&gt; ext. &lt;integer list&gt;
     '+' &lt;integer-list&gt; "(" integer list ")" &lt;integer-list&gt; ext. &lt;integer-list&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="auth-scheme">
       <core>
          <regex>
              ^(NONE|MAIL-FROM [^[:space:]]{1,80}|CRYPT-PW [A-Z0-9./]{13}|PGPKEY-[A-F0-9]{8})$
          </regex>
       </core>
       <description>
&lt;auth-scheme&gt; &lt;scheme-info&gt;       Description

NONE                              No authentication is required to
                                  make changes to the object protected
                                  with such authentication scheme.

MAIL-FROM     regular expression  This authentication method checks
              that matches        the content of the RFC 2822 "From:"
              e-mail addresses    header of an update request against
                                  the regular expression specified as
                                  &lt;scheme-info&gt;.  If the regular
                                  expression matches the content of
                                  the "From:" header, the update
                                  request is authenticated
                                  successfully. The regular
                                  expressions supported are described
                                  in POSIX 1003.2 section 2.8. As it
                                  is expected that most regular
                                  expressions will either be literals
                                  or of a form similar to
                                  .*@some.domain.or.other an extensive
                                  description of the possibilities
                                  will not be given. Note that the
                                  matching is applied to the whole
                                  content of the "From:" header
                                  including comments if present. No
                                  attempt is made to isolate the
                                  mailbox part.

                                  This authentication scheme is very
                                  weak. Forging RFC 822 headers does
                                  not take much effort or ingenuity.
                                  The reason for the scheme's
                                  existence is that it easily prevents
                                  accidental updates rather than
                                  allowing them first and fixing them
                                  later when notified.

CRYPT-PW      encrypted           This scheme is slightly stronger
              password, produced  than the MAIL-FROM scheme.  It is by
              by UNIX crypt(3)    no means meant to keep out a
              routine             determined malicious attacker.  The
                                  crypt function is vulnerable to
                                  exhaustive search by (lots of) fast
                                  machines and programs to do the
                                  searching are widely available. For
                                  this reason it is strongly
                                  discouraged to use encrypted
                                  passwords also used for other
                                  purposes such as UNIX login accounts
                                  in this scheme. As you are
                                  publishing the encrypted password in
                                  the database, it is open to attack.
                                  The usual caveats about crypt
                                  passwords apply, so it is not very
                                  wise to use words or combinations of
                                  words found in any dictionary of any
                                  language.

PGPKEY-&lt;id&gt;                       Strong scheme of authentication.
                                  &lt;id&gt; is the PGP key ID to be
                                  used for authentication. This string
                                  is the same one that is used in the
                                  corresponding key-cert object's
                                  "key-cert:" attribute.
       </description>
   </attribute_syntax>

   <attribute_syntax name="inetnum">
       <front_end>
           <regex>
^((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])) - ((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))$
           </regex>
       </front_end>
       <description>
     &lt;ipv4-address&gt; - &lt;ipv4-address&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="inet6num">
       <front_end>
           <parser_name>inet6num</parser_name>
       </front_end>
       <description>
     &lt;ipv6-address&gt;/&lt;prefix&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="country-code">
       <front_end>
           <regex>^[A-Z]{2}$</regex>
       </front_end>
       <description>
     Valid two-letter ISO 3166 country code.
       </description>
   </attribute_syntax>

   <attribute_syntax name="status-in">
       <front_end>
           <regex>
           ^((ALLOCATED (PA|PI|UNSPECIFIED))|((ASSIGNED|LIR-PARTITIONED) (PA|PI)))$
           </regex>
       </front_end>
       <description>
     Status can have one of these values:

     o ALLOCATED PA
     o ALLOCATED PI
     o ALLOCATED UNSPECIFIED
     o LIR-PARTITIONED PA
     o LIR-PARTITIONED PI
     o ASSIGNED PA
     o ASSIGNED PI
       </description>
   </attribute_syntax>

   <attribute_syntax name="status-i6">
       <front_end>
           <regex>
               ^(NLA|SLA|TLA|subTLA)$
           </regex>
       </front_end>
       <description>
     Status will be generated, and take one of these values:

     o TLA
     o SubTLA
     o NLA
     o SLA
       </description>
   </attribute_syntax>

   <attribute_syntax name="mnt-routes">
       <core>
          <regex>
              ^[A-Z]([A-Z0-9_-]){1,80}([[:space:]]+.*)*$
          </regex>
       </core>   
       <front_end>
           <!-- should probably be done as a Lex/Yacc file -->
           <regex>
^(([A-Z]([A-Z0-9_-]*[A-Z0-9])?( *\{( *(((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))(^(-|\+|[0-9]+|[0-9]+-[0-9]+))? *,)*( *((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))(^(-|\+|[0-9]+|[0-9]+-[0-9]+))?))? *\})?)|ANY)$
           </regex>
           <!-- ANY allowed -->
           <reserved_regex>
               ^(peeras|and|or|not|atomic|from|to|at|action|accept|announce|except|refine|networks|into|inbound|outbound|as-.*|rs-.*|rtrs-.*|fltr-.*|prng-.*|irt-.*)$
           </reserved_regex>
       </front_end>
       <description>
     &lt;mnt-name&gt; [ { list of &lt;address-prefix-range&gt; } | ANY ]
       </description>
   </attribute_syntax>

   <attribute_syntax name="public-key">
       <!-- do we care what is in here? -->
       <description>
     The value of the public key should be supplied either using
     multiple "certif:" attributes, or in one "certif:"
     attribute. In the first case, this is easily done by
     exporting the key from your local key ring in ASCII armored
     format and prepending each line of the key with the string
     "certif:". In the second case, line continuation should be
     used to represent an ASCII armored format of the key. All
     the lines of the exported key must be included; also the
     begin and end markers and the empty line which separates the
     header from the key body.
       </description>
   </attribute_syntax>

   <attribute_syntax name="fingerpr">
       <front_end>
           <regex>
               ^(([A-F0-9]{4} ){9}[A-F0-9]{4})|(([A-F0-9]{2} ){15}[A-F0-9]{2})$
           </regex>
       </front_end>
       <description>
     Attribute generated by server.
       </description>
   </attribute_syntax>

   <attribute_syntax name="key-cert">
       <core>
         <regex>
               ^PGPKEY-[A-F0-9]{8}$
          </regex>
       </core>   
       <front_end>
           <regex>
               ^PGPKEY-[A-F0-9]{8}$
           </regex>
       </front_end>
       <description>
     PGPKEY-&lt;id&gt;

     &lt;id&gt; is  the PGP key ID of the public key in 8-digit
     hexadecimal format without "0x" prefix.
       </description>
   </attribute_syntax>

   <attribute_syntax name="method">
       <front_end>
           <regex>
               ^PGP$
           </regex>
       </front_end>
       <description>
     Currently, only PGP keys are supported.
       </description>
   </attribute_syntax>

   <attribute_syntax name="address-prefix">
       <front_end>
           <regex>
^((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))/([12]?[0-9]|3[012])$
           </regex>
       </front_end>
       <description>
     An address prefix is represented as an IPv4 address followed
     by the character slash "/" followed by an integer in the
     range from 0 to 32.  The following are valid address
     prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the
     following address prefixes are invalid: 0/0, 128.9/16 since
     0 or 128.9 are not strings containing four integers.
       </description>
   </attribute_syntax>

   <attribute_syntax name="as-number">
       <core>
           <regex>^.{1,7}$</regex>
       </core>
       <front_end>
           <regex>
              ^AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-4])$
           </regex>
       </front_end>
       <description>
     An "AS" string followed by an integer in the range from 1 to
     65534
       </description>
   </attribute_syntax>

   <attribute_syntax name="as-block">
       <core>
           <regex>
              ^AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-4]) - AS([1-9][0-9]{0,3}|[1-5][0-9]{4}|6[0-4][0-9]{3}|65[0-4][0-9]{2}|655[0-2][0-9]|6553[0-4])$
           </regex>
       </core>
       <description>
     &lt;as-number&gt; - &lt;as-number&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="limerick">
      <core>
          <regex>
              ^.{1,80}$
          </regex>
       </core>
       <front_end>
          <regex>
              ^lim-[A-Z0-9_-]*$
          </regex>
       </front_end>
       <description>
     LIM-&lt;string&gt;

     &lt;string&gt; can include alphanumeric characters, and "_" and 
     "-" characters.
       </description>
   </attribute_syntax>

   <attribute_syntax name="components">
       <front_end>
         <parser_name>components</parser_name>
       </front_end>
       <description>
     [ATOMIC] [[&lt;filter&gt;] [protocol &lt;protocol&gt; &lt;filter&gt; ...]]

     &lt;protocol&gt; is a routing routing protocol name such as
     BGP4, OSPF or RIP

     &lt;filter&gt; is a policy expression
       </description>
   </attribute_syntax>

   <attribute_syntax name="aggr-mtd">
       <front_end>
         <parser_name>aggr_mtd</parser_name>
       </front_end>
       <description>
     inbound | outbound [&lt;as-expression&gt;]
       </description>
   </attribute_syntax>

   <attribute_syntax name="aggr-bndry">
       <front_end>
         <parser_name>aggr_bndry</parser_name>
       </front_end>
       <description>
     [&lt;as-expression&gt;]
       </description>
   </attribute_syntax>

   <attribute_syntax name="default">
       <front_end>
         <parser_name>default</parser_name>
       </front_end>
       <description>
     to &lt;peering&gt; [action &lt;action&gt;] [networks &lt;filter&gt;]
       </description>
   </attribute_syntax>

   <attribute_syntax name="export">
       <front_end>
         <parser_name>export</parser_name>
       </front_end>
       <description>
     to &lt;peering-1&gt; [action &lt;action-1&gt;] 
         .
         .
         .
     to &lt;peering-N&gt; [action &lt;action-N&gt;] 
     announce &lt;filter&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="import">
       <front_end>
         <parser_name>import</parser_name>
       </front_end>
       <description>
     [protocol &lt;protocol-1&gt;] [into &lt;protocol-1&gt;]
     from &lt;peering-1&gt; [action &lt;action-1&gt;] 
         .
         .
         .
     from &lt;peering-N&gt; [action &lt;action-N&gt;] 
     accept &lt;filter&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="ifaddr">
       <front_end>
         <parser_name>ifaddr</parser_name>
       </front_end>
       <description>
     &lt;ipv4-address&gt; masklen &lt;integer&gt; [action &lt;action&gt;]
       </description>
   </attribute_syntax>

   <attribute_syntax name="inject">
       <front_end>
         <parser_name>inject</parser_name>
       </front_end>
       <description>
     [at &lt;router-expression&gt;]
     [action &lt;action&gt;]
     [upon &lt;condition&gt;]
       </description>
   </attribute_syntax>

   <attribute_syntax name="peering">
       <front_end>
         <parser_name>peering</parser_name>
       </front_end>
       <description>
     &lt;peering&gt;
       </description>
   </attribute_syntax>

   <attribute_syntax name="peer">
       <front_end>
         <parser_name>peer</parser_name>
       </front_end>
       <description>
     &lt;protocol&gt; &lt;ipv4-address&gt; &lt;options&gt;
     | &lt;protocol&gt; &lt;inet-rtr-name&gt; &lt;options&gt;
     | &lt;protocol&gt; &lt;rtr-set-name&gt; &lt;options&gt;
     | &lt;protocol&gt; &lt;peering-set-name&gt; &lt;options&gt;
       </description>
   </attribute_syntax>

</rpsl_syntax>

