Hi Spencer, all, On 16 Feb 2017, at 06:47, Spencer Dawkins <[email protected]> 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 don't think I can enumerate all corner cases, and believe the document should not try to go there. > > 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. > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
