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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Feb 2017 21:47:46 -0800

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.

      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.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 16 Feb 2017 16:26:16 +0100

Hi Spencer, all,

> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/

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.

>      current validated manifest.

I can live with a "MUST NOT remove" here, but not sure that others agree.

> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Oleg Muravskiy <[email-masked]>
Date: Thu, 16 Feb 2017 17:19:49 +0100

Hi Tim, all,

> On 16 Feb 2017, at 16:26, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Hi Spencer, all,
> 

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Feb 2017 11:22:09 -0600

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

On Thu, Feb 16, 2017 at 9:26 AM, Tim Bruijnzeels <[email-masked]> wrote:

> 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.

> 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