Hi Tim, all, > On 16 Feb 2017, at 16:26, Tim Bruijnzeels <t...@ripe.net> wrote: > > Hi Spencer, all, > > On 16 Feb 2017, at 06:47, Spencer Dawkins <spencerdawkins.i...@gmail.com> > wrote: >> >> ---------------------------------------------------------------------- >> 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.
I wouldn't go for MUST here, because, strictly speaking, there might not even be a local cache, it depends on how the validation is implemented. We could either say "NOT RECOMMENDED ... if the local cache is used", or change this whole paragraph to a non-normative text, and possibly move it to Security Considerations. And in this case the previous paragraph could change into "MUST update its last processed serial number", leaving the local cache out. Oleg _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
