Re: [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc

[Jori Vanneste via db-wg]

Hi Ed,

On 4/8/2021 3:36 PM, Edward Shryane via db-wg wrote:

Hi Jori,

On 8 Apr 2021, at 14:42, Tyrasuki <tyras...@pm.me> wrote:

Hi Ed,

This seems like a good implementation to me.

However, I don't think it's a good idea to limit the values on the "remarks" 
attribute in this way, as this could cause unwanted side effects with for ex. messages 
left on objects for other network operators.

Given the draft states:

" Any particular inetnum: object MAY have, at most, one geofeed
    reference, whether a remarks: or a proper geofeed: attribute when one
    is defined."

Do we enforce this by validating that there is only one "remarks: Geofeed" value (or 
"geofeed:") in the object?

My apologies, I think I missed this section in the draft, thanks for clarifying the reason to me.

Also:

"Do not support non-ASCII values in URL domain names or path (these must be 
converted beforehand)"

Do you by this mean not supporting non-ASCII entirely? Or to have for ex. the 
web-interface convert IDNs to punycode, and have this listed on the object?

The RIPE database uses the Latin-1 character set, so IDN domain names or 
non-ASCII values in the URL path will be substituted with a '?' character, by 
default.

We could support non-ASCII values by automatically converting them (like we do 
with non-ASCII domains in email addresses).

That sounds like a good approach to me, thanks for clarifying. :)

I think this is indeed a good starting ground for a minimal NWI, and would like to see where this goes.

If the latter, and remarks can remain free-form, I'd say let's implement.


Cheers,
Jori Vanneste
FOD11-RIPE

Regards
Ed

Best regards,
Jori Vanneste
FOD11-RIPE

OpenPGP_0x27A401F86B85D0BC.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

signature.asc
Description: OpenPGP digital signature