Proposal for extended syntax for the 'country:' attribute

Dear all,

Recently, we ran into some inconsistencies that resulted from the
'country:' attribute as used in 'inetnum:' objects. Hereby, I want to
describe the (small) problems we found and propose possible solutions.


Problem description:

The RIPE NCC currently gets address space allocated from IANA for
assignment to local registries in our working area. This allocated
address space needs to registered in the RIPE database. Currently, we
fill the country attribute with the value 'EU', but we feel that it is
not the right representation since the address space is meant to be used
for the whole working area of RIPE.

Example:

inetnum:     193.0.0.0 - 193.255.255.255
country:     EU
[ ... stuff deleted... ]

The same problem exists for multinational registries that get address
space allocated that is used in more then one country.


Solutions:

Since we are dealing with a small, though highly visible problem we need
easy and quick fixes to avoid putting too much work in something that's
not really worth it ;-). We present them here in order of our preference:

1) we allow multiple country codes in the 'country:' attribute and allow
   for multiple line 'country:' code attributes for long lists of country
   codes.
  
   Pros:
  
   Solves the problem completely, is politically correct, easy to implement
  
   Cons:
  
   Might be a little bit overkill, especially if you look at the number of
   countries in the RIPE area.

2) Make country attribute optional since it doesn't really matter were the
   address space is used 

   Pros:
  
   Solves the problem completely, is politically correct, very easy to
   implement
  
   Cons:
  
   We loose some information that might be useful (for what?)

3) We invent new country codes for non-existing entities like EU.

   Pros:
  
   Solves the problem.

   Cons:
  
   not politically correct, we might need to define more names. We get
   discussions like EU is something else then the RIPE working area that is
   much bigger. We might need more different codes. We might get funny
   things when ISO is defining new country codes (that might be the same as
   our pseudo codes), which happens all to often in Europe and around...   

4) A combination of the proposed solutions, e.g. make the attribute
   optional *and* allow multiple country codes.

5) We leave it as it is
  
   Pros:
  
   The easiest thing
  
   Cons:
  
   We keep the inconsistencies
  

Please advise us. We have the idea that this topic is really something
for an interesting academic debate ;-), though we feel that we need to do
something to solve this problem!

David Kessens
RIPE NCC