Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback

["Gould, James" <[e-mail]>]

Jasdip,

I view the decision to redact or not redact purely a server policy decision, where the redacted extension is available for servers to implement their policy.  My recommendation is to leave the redaction policy out of draft-ietf-regext-rdap-geofeed altogether, so don’t include the SHOULD NOT redact language.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Jasdip Singh <[e-mail]>
Date: Monday, April 1, 2024 at 6:24 PM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Thanks, James.

But, to your “use of redaction is a policy decision for a server” point, since this spec would no longer espouse redaction for geofeed files, should it instead say that “server operators SHOULD NOT redact geofeed files given they are public resources already”?

Jasdip

From: Gould, James <[e-mail]>
Date: Monday, April 1, 2024 at 12:30 PM
To: Jasdip Singh <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback
Jasdip,

I don’t see an issue with removing the redaction section from draft-ietf-regext-rdap-geofeed, since I believe the use of redaction is a policy decision for a server.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://secure-web.cisco.com/1Q8aIg6JCbd1dOq8tmNbZJoAQCrMTIyEPp8A4wiVvDTx-mGmBGpUF7zfFQDh2bBRzzRrUuQGwITHbG5RGKlFlJBHNVIT_nsbnGMw-vaWx5NshXzoMFx2-SHStsdemnegenlA10PqYRmGIIgvVd6ZFci6IM2EnWYw4InrzYpwtqwxkOf3H91sHSkb1W2WYFWm7BGhG1Q0XAeqFQ5TCL8do6f_5mq7S36A7xzm7gPEphJlmwbXVDISMaV0vUEWuWaUhZJpLTG4LBz7bwbnSZDjGdZj_wLCAzb-n1vxVsSXQsxc/http%3A%2F%2Fverisigninc.com%2F>

From: Jasdip Singh <[e-mail]>
Date: Monday, April 1, 2024 at 12:12 PM
To: "Andrew Newton (andy)" <[e-mail]>
Cc: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Andy,

Thanks for your feedback. One comment below.

Jasdip

From: Andrew Newton (andy) <[e-mail]>
Date: Monday, April 1, 2024 at 11:42 AM
To: Jasdip Singh <[e-mail]>
Cc: Gould, James <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback
> I recommend including a registration of the "Geofeed links" redacted "name" in the RDAP JSON Values registry with the "redacted name" type field.  If registered, the "description" member can be changed to a "type" member.
>
> [JS] Good idea. Will do.

Is this really necessary? Under what conditions will a network
operator be publishing this public CSV file that then requires an RIR
to redact the link to it?

[JS] I guess we were pre-emptively trying to tackle redaction for geofeed links :) but your point about such files already being public seems to make redaction unnecessary here.

Question for the WG: Are we ok with removing redaction from the RDAP Geofeed draft?