Intersting observation, thanks for bringing it up! Q to the DB Team: is the software doing any checks against numeric values as numbers or is the data treated/stored exclusively as text? As a sort of more general sideline, there may be other limits or boundary conditions, and I am wondering where the proper place is to "enforce" those. I know about the 'be rigorous about what you transmit and liberal (and careful) in what you accept'. But I wonder whether that would not apply to tools just equally? Wilfried Job Snijders wrote:
Dear RIPE DB group,
A small snippet from the current AS15562 object as stored in the RIPE DB.
remarks: Larger than 32bit BGP Community test remarks: 64 bit export: to AS199036 action community .= { 0000199036:0000199036 }; announce AS-SNIJDERS
The value "0000199036:0000199036" is a 64 bit integer:
(199036<<32)+199036 = 854853110925692
854853110925692 Is far larger than what RFC 2622 [1] allows in section 7.1:
typedef: # a community value in RPSL is either # - a 4 byte integer (ok to use 3561:70 notation) # - internet, no_export, no_advertise (see RFC-1997 ) community_elm union integer[1, 4294967295], enum[internet, no_export, no_advertise],
So my main question is, why is the RIPE DB allowing such values to be stored?
This is not conforming to any specification that I am aware of. Currently there is no consensus on what the future of BGP communities will look like within the IETF.
Kind regards,
Job