This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Previous message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Next message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tyrasuki
tyrasuki at pm.me
Thu Apr 8 14:42:33 CEST 2021
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. 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? If the latter, and remarks can remain free-form, I'd say let's implement. Cheers, Jori Vanneste FOD11-RIPE \-------- Original Message -------- On Apr 8, 2021, 2:27 PM, Edward Shryane via db-wg < db-wg at ripe.net> wrote: > > > > > > > > > > > Hi Randy, > > > > > On 8 Apr 2021, at 13:54, Randy Bush via db-wg <db-wg at ripe.net> wrote: > > > > > >> Could we consider creating an NWI with a reduced scope? > > > > > > as an exercise, how minimal can we get? > > > > > > randy > > > > > > > Given the draft RFC: > > [https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?include\_text=1][https_datatracker.ietf.org_doc_draft-ietf-opsawg-finding-geofeeds_include_text_1] > > > > I suggest the following minimal Solution Definition for an NWI: > > > > \- Implement support for an optional, single "geofeed:" attribute in inetnum and inet6num object types. > > \- Validate there is a maximum of either one "remarks: Geofeed" or "geofeed:" attribute per object. > > \- Validate the "geofeed:" URL is well-formed and specifies the HTTPS protocol. > > \- Include the "geofeed:" attribute in database dumps and split files. > > > > And inversely, what we could leave out (to simplify the implementation): > > > > \- Do not support non-ASCII values in URL domain names or path (these must be converted beforehand) > > \- Do not migrate (re-write) "remarks: Geofeed" values as "geofeed:" attributes > > \- Do not validate that the URL is reachable (available) and do not validate the content > > > > Is this enough to satisfy the draft requirements? Is it enough to be useful for the DB-WG? > > > > Regards > > Ed Shryane > > RIPE NCC > > > > [https_datatracker.ietf.org_doc_draft-ietf-opsawg-finding-geofeeds_include_text_1]: https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?include_text=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/db-wg/attachments/20210408/ebf2b99b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/db-wg/attachments/20210408/ebf2b99b/attachment.sig>
- Previous message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
- Next message (by thread): [db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]