Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

[Terry Manderson <[e-mail]>]

On 18/07/11 9:39 PM, "Tim Bruijnzeels" <[e-mail]> wrote:

> Hi,
> 
> I agree that not having this mapping is tedious and error prone for RPs.

I can agree that a mapping system is useful. It may just be that living unix
world for far too long has seen me move away from the mandatory dos-like
suffixes to the voluntary use of extensions in a unix file system as a
*hint* to the file contents and nothing more.

And I'm happy to see it written as a hint. A validated mapping should come,
in my opinion from something more robust which also transcends the
technology used in the repository.

> 
> Example:
> - ROA that isn't strictly standard compliant / validator has bug in ROA
> recognition
> 
> Validator tries to parse as roa, cer, crl, mft; then gives up...
> 

So the validator has a bug. fix the validator?

> This is not only ugly code to maintain, it also makes it difficult to debug
> problems. The happy flow case, while cumbersome, is not the biggest problem
> here I think..
> 
> How do we work out, in this example, what caused the actual problem? From the
> software side it's rather involved to build something like: this looks 99%
> like I ROA, one I don't understand, but it's probably what they meant or
> something like that... so our tool just says: I don't understand this
> *object*.
> 

Same goes for a misname (malicious or otherwise) of the file. A robust
mechanism as I see it doesn't live in three letter extensions.

> 
> Whether this mapping strictly needs to be in this draft may be another
> question.
> 

Agree with that point.

Cheers
Terry