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

[Spencer Dawkins at IETF]

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

On Thu, Feb 16, 2017 at 9:26 AM, Tim Bruijnzeels  wrote:

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

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

[Oleg Muravskiy]

Hi Tim, all,

> On 16 Feb 2017, at 16:26, Tim Bruijnzeels  wrote:
> 
> Hi Spencer, all,
> 
> On 16 Feb 2017, at 06:47, Spencer Dawkins  
> 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