Thanks Anand for addressing the feedback. 1. I'd recommend adding a Rotate encryption key REST endpoint to IRC, so that it works across engines. If IRC does not take it, we can consider to define a Polaris specific approach. 2. The checksum is acceptable to me as an initial step., but may not be sufficient if users want to hide it, as it is currently plain text. It's reasonable as phase one. We can continue exploring options such as making metadata.json optional or leveraging storage level permissions for stronger protection. 3. Will take a close look later 4. It makes sense to take a phased-in approach.
Yufei On Thu, Feb 12, 2026 at 6:39 PM Anand Kumar Sankaran < [email protected]> wrote: > Yufei, Mike, Prashant, Russell > > Thank for you for your detailed feedback. I have updated the RFC > <https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing> > based > on your feedback. I request you to look at the RFC again. I marked some > comments as resolved just so that I know what I need to focus on next, > please feel free to reopen. > > I think we need agreement on the following: > > > 1. Rotate encryption key REST endpoint: Do we need to wait for IRC to > add this? There is an old PR #2373 that was closed as not planned > <https://github.com/apache/iceberg/issues/2373>. If we want to wait > for IRC, can this work still be done without the REST endpoint? > 2. Is the proposal for protecting metadata.json using checksum > sufficient > > <https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?tab=t.0#heading=h.hj35el4zxapx> > and > acceptable? > 3. Is the proposed Key Rotation semantics > > <https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?tab=t.0#heading=h.3p1v44t5whpl> > acceptable? > 4. Can snapshot-to-snapshot migration path be deferred to another > follow up RFC / design? > > > In general, this feels like a lot of work to be done in one go. I would > appreciate any guidance on how to break this down into smaller chunks to > make progress. > > Thanks again. > > — > Anand > > *From: *Yufei Gu <[email protected]> > *Date: *Monday, February 9, 2026 at 10:56 AM > *To: *[email protected] <[email protected]> > *Cc: *Anand Kumar Sankaran <[email protected]> > *Subject: *Re: RFC for table-level encryption support (#2829) > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/Iz9xO38YGHZK!YhNDZABkHi1B6_pOVSGpMMuQc0CmP3OULNHOAUHUwYVTgbsx_oh5Ze7QOuU7LW1BuqjeDCi1LpG0R1DEuMHUCxOCo0hQG1mi4VmtapPKGSElXop473V-D5mKBlzl65oK$> > > Hi Anand, thanks for the RFC. I think it's the right direction, which may > significantly promote the use of the Iceberg Table encryption. Left some > comments. I think we still need to determine which part would be better > suited for IRC and how we will protect metadata.json better. > > Yufei > > > On Mon, Feb 9, 2026 at 9:33 AM Michael Collado <[email protected]> > wrote: > > Very awesome to see. I left a few comments in the doc. > > Mike > > On Mon, Feb 9, 2026 at 8:12 AM Anand Kumar Sankaran via dev < > [email protected]> wrote: > > > Hi all > > > > Please find an RFC for table-level encryption support. > > > https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing > <https://urldefense.com/v3/__https://docs.google.com/document/d/1f4Mgg5W1t4NT6R7KLq5K3S4pHlAwYwXTFwUR9uNNpSU/edit?usp=sharing__;!!Iz9xO38YGHZK!_Cc4ra1dyOvDg7UuabtBS1JqIdb7-ZLvhB0sCEvp1mNohZDTHqUj4QdsSiYNdc52VM7togKNDyMdHIKbbRsb2BI$> > > > > The feature request for this feature can be found here: > > https://github.com/apache/polaris/issues/2829 > <https://urldefense.com/v3/__https://github.com/apache/polaris/issues/2829__;!!Iz9xO38YGHZK!_Cc4ra1dyOvDg7UuabtBS1JqIdb7-ZLvhB0sCEvp1mNohZDTHqUj4QdsSiYNdc52VM7togKNDyMdHIKb4Th5C-Q$> > . > > > > I appreciate any feedback and critical reviews from you. > > > > — > > Anand > > > >
