Re: [db-wg] Clear up of old issues - Whiepages
Hi Cynthia On Tue, 22 Feb 2022 at 21:02, Cynthia Revström wrote: > > Oh right I forgot to add: > > > Why is it important to know what objects are protected from deletion? > If it is not referenced by any resource object (directly or > indirectly) and it is still in the DB in 3 months time, it is > protected. > > It is just because you will not know if it is protected until it is > deleted, so if it is not protected you will not know until it is too > late. On this point I would hope that if you agree this with the NCC and they confirm to you that it is protected then you can trust the NCC. In a worst case scenario the NCC is able to restore deleted PERSON/ROLE objects with the same NicHdl. cheers denis co-chair DB-WG > > -Cynthia > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
> The RIPE NCC are creating /24 top-level allocations, but this size could also > be used as a single (second level) assignment. However, we don't have a way > (yet, see NWI-4) to distinguish between an allocation and assignment of the > same size. Geofeed is allowed on a top-level resource but not on a more > specific assignment within that. I hope you only mean for /24 and /48 (or more specific), as in I hope I would still be able to add a geofeed attribute to for example a /32 under the /29 allocated to the LIR by the NCC. -Cynthia On Tue, Feb 22, 2022 at 10:35 AM Edward Shryane via db-wg wrote: > > Hi Denis, > > > On 21 Feb 2022, at 17:10, denis walker wrote: > > > > Hi Ed > > > > Can you clarify this comment... > > > >> > >> Our Legal team have considered the concerns from a part of the community > >> regarding the eligible size for “geofeed:” validation and concluded the > >> following: > >> Since resources with prefix size equal to the size distributed/registered > >> by the RIPE NCC to a resource holder is not considered to be personal > >> data, an equal prefix size may receive the “geofeed:” validation. > >> > >> Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level > >> ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for > >> IPv6). > > > > Are you saying you will ONLY allow geofeed on resources with these > > status values? What about SUB-ALLOCATED PA and AGGREGATED-BY-LIR? The > > nature of these status values suggests they are not personal data. > > > > Legal have made a distinction between the resources allocated or assigned by > the RIPE NCC and resources assigned on a second level by our members or > provider independent resource holders. > > If SUB-ALLOCATED PA and AGGREGATED-BY-LIR are not personal data (since they > are used for grouping network blocks together), then we can allow "geofeed:" > on them. > > > "an equal prefix size may receive the “geofeed:” validation." > > Or are you saying any object with a size equal to any allocation can > > have a "geofeed:" attribute? That would mean a /24 for IPv4. > > > > The RIPE NCC are creating /24 top-level allocations, but this size could also > be used as a single (second level) assignment. However, we don't have a way > (yet, see NWI-4) to distinguish between an allocation and assignment of the > same size. Geofeed is allowed on a top-level resource but not on a more > specific assignment within that. > > Regards > Ed Shryane > RIPE NCC > > > > cheers > > denis > > co-chair DB-WG > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Clear up of old issues - Whiepages
Oh right I forgot to add: > Why is it important to know what objects are protected from deletion? If it is not referenced by any resource object (directly or indirectly) and it is still in the DB in 3 months time, it is protected. It is just because you will not know if it is protected until it is deleted, so if it is not protected you will not know until it is too late. -Cynthia On Tue, Feb 22, 2022 at 9:00 PM Cynthia Revström wrote: > > > Just a side point for people to think about, should the NCC only offer > to protect ROLE objects that do not contain personal data? > > I do not think so, I still want to keep the functionality of > whitepages, I only agree with removing duplicate implementations of > it. > > I know that both me and several others do use handles in various cases > like contact information in presentations. > While you can argue about how valid this use case is, I think the cat > is kinda out of the bag, and we need to keep supporting this use case > for those who explicitly say they want it. > Unless the NCC legal team has a problem with it that is, but I hope > and would think they don't as these are cases when the person in > question has explicitly requested it to be protected. > > -Cynthia > > On Tue, Feb 22, 2022 at 4:18 PM denis walker wrote: > > > > Hi Cynthia > > > > I just checked and currently there are only 4 people using the > > whitepages and 1 of them is NCC staff. Certainly they will be > > contacted before deleting the feature. > > > > Why is it important to know what objects are protected from deletion? > > If it is not referenced by any resource object (directly or > > indirectly) and it is still in the DB in 3 months time, it is > > protected. > > > > Just a side point for people to think about, should the NCC only offer > > to protect ROLE objects that do not contain personal data? The only > > reason for protecting objects is for contact details needed for other > > services by non resource holders. Perhaps we should not be protecting > > personal data that is not related to resources. Contact details do not > > need to be personal. > > > > cheers > > denis > > co-chair DB-WG > > > > On Tue, 22 Feb 2022 at 01:26, Cynthia Revström wrote: > > > > > > Hi Denis, > > > > > > While I kinda support this, I also like how the whitepages feature > > > allows you to easily see if an object was protected from deletion or > > > not. > > > > > > Would it be possible to add some kind of extra data in the whois > > > response for protected objects? (like the data about abuse email when > > > you query for an ASN or IP address/prefix) > > > > > > Regardless, given the low number of protected handles, I think it > > > makes sense to contact them before doing this and protect them using > > > the new method unless they object to it. > > > > > > -Cynthia > > > > > > On Mon, Feb 21, 2022 at 3:56 PM denis walker via db-wg > > > wrote: > > > > > > > > Colleagues > > > > > > > > The co-chairs recently had a zoom meeting with the RIPE NCC. One of > > > > the things we discussed was clearing up a number of old issues. We > > > > need to clear the deck and move on with new and perhaps more relevant > > > > issues. We will address a number of issues for the last time. In some > > > > cases the chairs will make a recommendation. As these are quite old > > > > issues, we will take silence as consensus for the chair's > > > > recommendation. > > > > > > > > The first issue is Whitepages. This is a feature from about 10+ years > > > > ago. It was intended to preserve the PERSON object in the RIPE > > > > Database and protect it from automatic deletion if it is not > > > > referenced from any operational data. It was to use the RIPE Database > > > > as a phone book for well known people in the industry who may not be > > > > resource holders. There are many other ways to provide such contact > > > > details today. It was only ever used by a handful of people. The RIPE > > > > NCC now has other ways to preserve ROLE objects if needed, for example > > > > if used by RIPE Atlas users. > > > > > > > > The chairs recommend removing this feature from the RIPE Database. If > > > > you need a ROLE object to be preserved, contact ripe-...@ripe.net to > > > > discuss. > > > > > > > > cheers > > > > denis > > > > co-chair DB-WG > > > > > > > > -- > > > > > > > > To unsubscribe from this mailing list, get a password reminder, or > > > > change your subscription options, please visit: > > > > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Clear up of old issues - Whiepages
> Just a side point for people to think about, should the NCC only offer to protect ROLE objects that do not contain personal data? I do not think so, I still want to keep the functionality of whitepages, I only agree with removing duplicate implementations of it. I know that both me and several others do use handles in various cases like contact information in presentations. While you can argue about how valid this use case is, I think the cat is kinda out of the bag, and we need to keep supporting this use case for those who explicitly say they want it. Unless the NCC legal team has a problem with it that is, but I hope and would think they don't as these are cases when the person in question has explicitly requested it to be protected. -Cynthia On Tue, Feb 22, 2022 at 4:18 PM denis walker wrote: > > Hi Cynthia > > I just checked and currently there are only 4 people using the > whitepages and 1 of them is NCC staff. Certainly they will be > contacted before deleting the feature. > > Why is it important to know what objects are protected from deletion? > If it is not referenced by any resource object (directly or > indirectly) and it is still in the DB in 3 months time, it is > protected. > > Just a side point for people to think about, should the NCC only offer > to protect ROLE objects that do not contain personal data? The only > reason for protecting objects is for contact details needed for other > services by non resource holders. Perhaps we should not be protecting > personal data that is not related to resources. Contact details do not > need to be personal. > > cheers > denis > co-chair DB-WG > > On Tue, 22 Feb 2022 at 01:26, Cynthia Revström wrote: > > > > Hi Denis, > > > > While I kinda support this, I also like how the whitepages feature > > allows you to easily see if an object was protected from deletion or > > not. > > > > Would it be possible to add some kind of extra data in the whois > > response for protected objects? (like the data about abuse email when > > you query for an ASN or IP address/prefix) > > > > Regardless, given the low number of protected handles, I think it > > makes sense to contact them before doing this and protect them using > > the new method unless they object to it. > > > > -Cynthia > > > > On Mon, Feb 21, 2022 at 3:56 PM denis walker via db-wg > > wrote: > > > > > > Colleagues > > > > > > The co-chairs recently had a zoom meeting with the RIPE NCC. One of > > > the things we discussed was clearing up a number of old issues. We > > > need to clear the deck and move on with new and perhaps more relevant > > > issues. We will address a number of issues for the last time. In some > > > cases the chairs will make a recommendation. As these are quite old > > > issues, we will take silence as consensus for the chair's > > > recommendation. > > > > > > The first issue is Whitepages. This is a feature from about 10+ years > > > ago. It was intended to preserve the PERSON object in the RIPE > > > Database and protect it from automatic deletion if it is not > > > referenced from any operational data. It was to use the RIPE Database > > > as a phone book for well known people in the industry who may not be > > > resource holders. There are many other ways to provide such contact > > > details today. It was only ever used by a handful of people. The RIPE > > > NCC now has other ways to preserve ROLE objects if needed, for example > > > if used by RIPE Atlas users. > > > > > > The chairs recommend removing this feature from the RIPE Database. If > > > you need a ROLE object to be preserved, contact ripe-...@ripe.net to > > > discuss. > > > > > > cheers > > > denis > > > co-chair DB-WG > > > > > > -- > > > > > > To unsubscribe from this mailing list, get a password reminder, or change > > > your subscription options, please visit: > > > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
> The RFC says "Until such time...". We have a "geofeed:" attribute now > so we are past 'such time'. We should no longer even consider, or > support, "remarks:'' as an option for geofeed. you have the wrong end of the horse. it is the seeker/fetcher of geofeed data who decides whether they look inside remarks: and/or geofeed: attributes. repeat ten times: "remarks are opaque and their interpretation is only in the eye of the beholder." [0] randy 0 - an american legal joke about pornography. quoting bloomberg In a 1964 decision, U.S. Supreme Court Justice Potter Stewart said he would not attempt to define hard-core pornography, and “perhaps I could never succeed in intelligibly doing so.” He famously added, “But I know it when I see it.” --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Clear up of old issues - Whiepages
Hi denis, > On 22 Feb 2022, at 16:18, denis walker via db-wg wrote: > > Hi Cynthia > > I just checked and currently there are only 4 people using the > whitepages and 1 of them is NCC staff. Certainly they will be > contacted before deleting the feature. I counted 5, none staff :) I consider myself contacted, proceed as the wg wishes. Wonder if this is the oldest object in the DB per its creation date. Joao -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Clear up of old issues - Whiepages
Hi Cynthia I just checked and currently there are only 4 people using the whitepages and 1 of them is NCC staff. Certainly they will be contacted before deleting the feature. Why is it important to know what objects are protected from deletion? If it is not referenced by any resource object (directly or indirectly) and it is still in the DB in 3 months time, it is protected. Just a side point for people to think about, should the NCC only offer to protect ROLE objects that do not contain personal data? The only reason for protecting objects is for contact details needed for other services by non resource holders. Perhaps we should not be protecting personal data that is not related to resources. Contact details do not need to be personal. cheers denis co-chair DB-WG On Tue, 22 Feb 2022 at 01:26, Cynthia Revström wrote: > > Hi Denis, > > While I kinda support this, I also like how the whitepages feature > allows you to easily see if an object was protected from deletion or > not. > > Would it be possible to add some kind of extra data in the whois > response for protected objects? (like the data about abuse email when > you query for an ASN or IP address/prefix) > > Regardless, given the low number of protected handles, I think it > makes sense to contact them before doing this and protect them using > the new method unless they object to it. > > -Cynthia > > On Mon, Feb 21, 2022 at 3:56 PM denis walker via db-wg wrote: > > > > Colleagues > > > > The co-chairs recently had a zoom meeting with the RIPE NCC. One of > > the things we discussed was clearing up a number of old issues. We > > need to clear the deck and move on with new and perhaps more relevant > > issues. We will address a number of issues for the last time. In some > > cases the chairs will make a recommendation. As these are quite old > > issues, we will take silence as consensus for the chair's > > recommendation. > > > > The first issue is Whitepages. This is a feature from about 10+ years > > ago. It was intended to preserve the PERSON object in the RIPE > > Database and protect it from automatic deletion if it is not > > referenced from any operational data. It was to use the RIPE Database > > as a phone book for well known people in the industry who may not be > > resource holders. There are many other ways to provide such contact > > details today. It was only ever used by a handful of people. The RIPE > > NCC now has other ways to preserve ROLE objects if needed, for example > > if used by RIPE Atlas users. > > > > The chairs recommend removing this feature from the RIPE Database. If > > you need a ROLE object to be preserved, contact ripe-...@ripe.net to > > discuss. > > > > cheers > > denis > > co-chair DB-WG > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or change > > your subscription options, please visit: > > https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
[db-wg] Removing Apache Proxy Servers from DB Services
Dear Colleagues, Next Tuesday, 1st March, the DB team plan to remove the Apache httpd proxy servers for the following services: * https://apps.db.ripe.net/ * https://rdap.db.ripe.net/ * https://rest.db.ripe.net/ * https://syncupdates.db.ripe.net/ This will allow us to simplify our production environment, reducing operational work and maintenance. Be aware that URL validation will be stricter after this change. For example, the following will return a 400 Bad Request: * Empty path segments (i.e. '//') * Encoded path separators (i.e. %2F for '/') * Encoded query separator (i.e. %3F for '?') Please test your client using the TEST environment: https://www.ripe.net/manage-ips-and-asns/db/ripe-test-database or the Release Candidate environment: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candidate-environment Regards Ed Shryane RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi Ed On Tue, 22 Feb 2022 at 09:54, Edward Shryane via db-wg wrote: > > Hi Massimo, > > > On 21 Feb 2022, at 16:29, Massimo Candela via db-wg wrote: > > > > Hi Ed, > > > > Thanks for the work done. > > > > Thank you! > > > > > On 21/02/2022 15:56, Edward Shryane via db-wg wrote: > > > >> We will also start enforcing the same validation on "remarks: geofeed" as > >> on "geofeed:" for consistency. > > > > I think you should not enforce anything on remarks. For what I know, > > remarks have been a free text field up to now. > > > > I agree! In general, Whois doesn't attempt to validate free-text fields, > since they can contain anything, in any format. > > However, the RFC draft that we base the implementation on, allows for a > "remarks: geofeed " as an alternative to a "geofeed:" attribute: > >Ideally, RPSL would be augmented to define a new RPSL geofeed: >attribute in the inetnum: class. Until such time, this document >defines the syntax of a Geofeed remarks: attribute which contains an >HTTPS URL of a geofeed file. The format MUST be as in this example, >"remarks: Geofeed " followed by a URL which will vary. > > (Ref. > https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds) > Just a point on the RFC. As I have said in many discussions recently, wording is important. The RFC says "Until such time...". We have a "geofeed:" attribute now so we are past 'such time'. We should no longer even consider, or support, "remarks:'' as an option for geofeed. (Maybe after a defined transition period of time.) We have a precedent for this with abuse contacts. People used to put them in "remarks:" until we introduced "abuse-c:". Now we advise people to use "abuse-c:" and not put abuse contact details in "remarks:". We should give the same advice for "geofeed:". Of course some people still put abuse details in "remarks:" as well, and they may continue to do so with "geofeed:". It has a free text format so people can put whatever they like there and the DB software should not try to parse it in any way. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
On 22/02/2022 13:33, Edward Shryane wrote: To be clear, the Legal review looked at the "geofeed:" attribute alone, and did not consider "remarks:". There is no requirement to validate "remarks:". Given this, and thanks to your feedback, I will drop my suggestion to validate "remarks:", and update the impact analysis for "geofeed:" only. Good! Thanks Ed! Ciao, Massimo -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi Job, Colleagues, > On 22 Feb 2022, at 10:01, Job Snijders wrote: > > On Tue, Feb 22, 2022 at 09:54:24AM +0100, Edward Shryane via db-wg wrote: >> Not doing any validation is not an option given the Legal review. > > Why not? > > Kind regards, > > Job To be clear, the Legal review looked at the "geofeed:" attribute alone, and did not consider "remarks:". There is no requirement to validate "remarks:". Given this, and thanks to your feedback, I will drop my suggestion to validate "remarks:", and update the impact analysis for "geofeed:" only. Regards Ed Shryane RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi Ed, On 22/02/2022 09:54, Edward Shryane wrote: (Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds) I remember that :) The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text). The RFC defines a structure for the user to insert their entries, and for the readers to parse those entries. But it does not say that the RIR should start validating remarks, and no other RIR is doing that. What was defined in NWI-13 was defined for the new "geofeed" attribute, not for remarks. By using remarks, the rfc promotes a self-organized approach to use current geofeed technology in current whois technology, it doesn't introduce nothing new in the logic of remarks. (2) Users can always encode the same information in remarks without geofeed (which would just increase the mess and bypass the check); Correct, I am proposing that we validate both equally to avoid this (we don't want an incentive for "remarks:"). What I meant is that, you can enforce a regex "geofeed URL" in remarks as much as you like, but as soon as users realize that, they can bypass that with another syntax. What it take it's just one big geolocation provider to suggest an alternative syntax. When things get too complicated, users find ways around it, making the problem worse. Correct, it's already possible to write anything in "remarks:", however if we don't validate we're giving an incentive to keep using "remarks:" for geofeed I am open to suggestions on how to resolve this. For example, instead of validating "remarks: geofeed", can this construction be deprecated (removed) in favour of "geofeed:" ? At the moment RIPE NCC is the only one having a specific field for "geofeed", so I would not drop the support for "remarks". It is also the only one validating "remarks". Honestly, for how it is getting complicated, I am more in favor of dropping "geofeed" and go back to remarks. Ciao, Massimo -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi Denis, > On 21 Feb 2022, at 17:10, denis walker wrote: > > Hi Ed > > Can you clarify this comment... > >> >> Our Legal team have considered the concerns from a part of the community >> regarding the eligible size for “geofeed:” validation and concluded the >> following: >> Since resources with prefix size equal to the size distributed/registered by >> the RIPE NCC to a resource holder is not considered to be personal data, an >> equal prefix size may receive the “geofeed:” validation. >> >> Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED >> PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6). > > Are you saying you will ONLY allow geofeed on resources with these > status values? What about SUB-ALLOCATED PA and AGGREGATED-BY-LIR? The > nature of these status values suggests they are not personal data. > Legal have made a distinction between the resources allocated or assigned by the RIPE NCC and resources assigned on a second level by our members or provider independent resource holders. If SUB-ALLOCATED PA and AGGREGATED-BY-LIR are not personal data (since they are used for grouping network blocks together), then we can allow "geofeed:" on them. > "an equal prefix size may receive the “geofeed:” validation." > Or are you saying any object with a size equal to any allocation can > have a "geofeed:" attribute? That would mean a /24 for IPv4. > The RIPE NCC are creating /24 top-level allocations, but this size could also be used as a single (second level) assignment. However, we don't have a way (yet, see NWI-4) to distinguish between an allocation and assignment of the same size. Geofeed is allowed on a top-level resource but not on a more specific assignment within that. Regards Ed Shryane RIPE NCC > cheers > denis > co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
On Tue, Feb 22, 2022 at 09:54:24AM +0100, Edward Shryane via db-wg wrote: > Not doing any validation is not an option given the Legal review. Why not? Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Hi Massimo, > On 21 Feb 2022, at 16:29, Massimo Candela via db-wg wrote: > > Hi Ed, > > Thanks for the work done. > Thank you! > > On 21/02/2022 15:56, Edward Shryane via db-wg wrote: > >> We will also start enforcing the same validation on "remarks: geofeed" as on >> "geofeed:" for consistency. > > I think you should not enforce anything on remarks. For what I know, remarks > have been a free text field up to now. > I agree! In general, Whois doesn't attempt to validate free-text fields, since they can contain anything, in any format. However, the RFC draft that we base the implementation on, allows for a "remarks: geofeed " as an alternative to a "geofeed:" attribute: Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document defines the syntax of a Geofeed remarks: attribute which contains an HTTPS URL of a geofeed file. The format MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary. (Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds) > In my view: > (1) RIPE NCC promotes the "geofeed" field for the geofeed purpose, instead, > using "remarks" it is not the practice suggested by RIPE NCC and so I don't > believe it is RIPE NCC's responsibility; The DB team have implemented the draft RFC to standardise "geofeed:", but "remarks:" is defined as the alternative. As "remarks:" can be used as an alternative to "geofeed:", if we don't also validate "remarks:" it can be used to bypass any validation done on "geofeed:". The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text). If the two constructions are considered equivalent by clients, any unequal validation on "geofeed:" will be a disincentive to replace "remarks:", and we will be left with both indefinitely. > (2) Users can always encode the same information in remarks without geofeed > (which would just increase the mess and bypass the check); Correct, I am proposing that we validate both equally to avoid this (we don't want an incentive for "remarks:"). > (3) starting to validate the content of remarks creates a precedent in which > RIPE NCC is responsible for checking remarks content (possibly, in the > future, not only about geofeeds). > Correct, it's already possible to write anything in "remarks:", however if we don't validate we're giving an incentive to keep using "remarks:" for geofeed. > But I don't know anything about legal things, so this is just my point of > view. > I am open to suggestions on how to resolve this. For example, instead of validating "remarks: geofeed", can this construction be deprecated (removed) in favour of "geofeed:" ? Not doing any validation is not an option given the Legal review. Regards Ed Shryane RIPE NCC > Ciao, > Massimo > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
