Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

Tim,
> ...
> In short: Given that I expect that we are never come to a consensus other than the total reject-all-if-one-fails - I can live with this if we must, but don't let it come as a surprise.
Works for me.
>> ...
>> Allowing RPs to ignore object types they don't understand prevents a CA from being able to convey the notion that a new object type is important (to that CA). I don't think this is a good strategy. It means that RP behavior will be ambiguous relative to new object types.
> So far none of the objects have seemed to need this flag.
If the goal is to define a very general scheme, then a flag may be 
necessary to accommodate objects not yet defined, since we cannot yet 
know whether a uniform response for all such objects will be 
appropriate. I agree that this need not be a binary flag, as in cert 
extensions. You suggested a three-value flag below, for example.
> ...
>> If we want to have a consistent and flexible approach to accommodating new objects I suggest the strategy I mentioned earlier. Define an additional SIA URI that points to a pub point (and manifest) where we can introduce the next version of the signed object format, one that includes a critical flag, analogous to X.509v3 extensions. This allows each CA to decide which object types have to be processed  by an RP in order for the whole pub point to be accepted vs. rejected. Note that this will require modifying a lot of RFCs, but it is a flexible, extensible approach to this issue.
> I agree that it's flexible and extensible. I had not thought of this approach.
>
> But it is a lot of work, not just in RFCs, also in code. It also raises questions about how and when old PPs without the new objects can be deprecated. You can give operators more time to upgrade, but at some point plugs will probably be pulled? Maintaining multiple PPs indefinitely seems rather wasteful.
>
> I would like to hear what others have to say.. I have the feeling that ASPA is getting close, and I would really not like to see it delayed because of this.
It will take a while to complete another revision of the manifest doc, 
if we purse additional changes, and even longer before an RFC is 
approved and published. So ASPA will not be accommodated quickly. Also, 
as I noted in my reply to jay, a quick read of the ASPA doc didn't 
indicate how these new objects are validated using the RPKI.
> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.

One could combine the new SIA URI and a revised manifest, in which the 
manifest contains the per-object flag, rather than redefining the basic 
object format to accommodate the flag. That would reduce the number of 
RFCs that need to change. Good idea.

Your example bothers me a bit- it seems to argue for CA-directed 
processing flags, perhaps to accommodate experimentation with new object 
types. This sounds like adopting elements of the IRR DB model which 
didn't seem to be so great, IMHO.

Separately, I think we need to make GBR mandatory for all pub points. If 
the intent is to cause RPs to contact a CA/pub point maintainer when 
errors are encountered, then we need to be confident that RPs know who 
to contact and how.

Steve