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