Hi, Tim (responding here, but I also saw Oleg's reply), On Thu, Feb 16, 2017 at 9:26 AM, Tim Bruijnzeels <t...@ripe.net> wrote:
> Hi Spencer, all, > > On 16 Feb 2017, at 06:47, Spencer Dawkins <spencerdawkins.i...@gmail.com> > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-sidr-delta-protocol-07: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I’m not skilled in the art of RPKI, so perhaps I lack imagination, but > > I'm not understanding why these two SHOULDs aren't MUSTs. I'm not asking > > for a change, but if the document included explanations of why an > > implementation might not do the SHOULDs, some readers might thank you. > > > > The RP SHOULD add all publish elements to a local storage and > > update its last processed serial number to the serial number of > > this delta file. > > corner cases: the RP already added this same object so strictly speaking > it's1 already there, the object is 5TB in size? I'm sorry this wasn't clear - the SHOULD applies to two actions ("and"), and I was thinking about the second action. Why would an implementation not update its last processed serial number? Would things still work? I agree that many RPs might not have a few terabytes lying around ... > I don't think I can enumerate all corner cases, and believe the document > should not try to go there. Agreed. I was trying to understand what a corner case would look like, not asking for a complete list of all corner cases. > > > > The RP SHOULD NOT remove objects from its local storage solely > > because it encounters a "withdraw" element, because this would > > enable a publication server to withdraw any object without the > > signing Certificate Authority consent. The RP could use > > additional strategies to determine if an object is still relevant > > for validation before removing it from its local storage. In > > particular objects should not be removed if they are included in > > a > > current validated manifest. > > I can live with a "MUST NOT remove" here, but not sure that others agree. > I saw that Oleg replied "but what if you don't even have local storage?" That's fair, but is that the only reason this isn't a MUST? Removing an object without consent from the signing Certificate Authority just seems unfortunate, and the SHOULD allows that. And thanks for the quick responses, both of you. Spencer > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
