Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

Hi, Tim (responding here, but I also saw Oleg's reply),

On Thu, Feb 16, 2017 at 9:26 AM, Tim Bruijnzeels <tim@ripe.net> wrote:

> Hi Spencer, all,
>
> On 16 Feb 2017, at 06:47, Spencer Dawkins <spencerdawkins.ietf@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
>
>