Should the DB reject such an update? Should the geofeed client pick
one at random? Should it pick the first one? Or the last one? Or none?
my personal opinion would be, as the spec says only one, an attempt to
add a second should fail. as should an initial attempt to create with
more than one.
Interesting. I was under the impression that the point for allowing the
alternative representation of using remarks: is to fit in the current
RPSL scheme, thereby not needing to change implementation. Rejection of
remarks:geofeed duplicates would violate that.
In other words, once an implementation enforces the single-instance
remarks:geofeed entry, it may as well enforce the geofeed: key
instead... To me that means that the enforcement of single-instance
remarks:geofeed entries is unlikely to happen.
Cheers,
Robert
