Re: [Secdispatch] Numeric IDs: Update to RFC3552

[Fernando Gont <[e-mail]>]

On 19/4/19 09:07, Hannes Tschofenig wrote:
> Hi Fernando,
> 
> I am not sure why it is important for you to update RFC 3552.

So that folks are required to do the corresponding analysis of numeric
I-Ds as part of the security considerations section?

FWIW, I think that's the *right* thing to do. That said, at this point,
I can live without that, if that's the "showstopper".




> The
> argument that it requires specification authors to consider your
> document in security and privacy considerations is not IMHO not
> correct. If you document provides useful guidance then it should
> stand on its own.

Again, while I do think the right thing is to update RFC3552, I'm not
planning to spend a lot of Joules fighting this point.



> A few random comments from looking at it:
> 
> - FWIW you should be re-using terms defined in RFC 6973, such as
> identifier.

Will check. Thanks for the pointer.


> - Why are you acknowledging yourself in your own draft? -

We're just noting that this document is a spin off of
gont-predictable-numeric-ids, because:

1) We cannot predict the faith of the other pieces

2) The folks we credit didn't provide feedback on this particular doc,
but on the larger document. Not crediting them would be unfair. Claiming
that they provided feedback on *this* document would be incorrect/not-true.



> You use the RFC 2119 term as requirements for protocol authors rather
> than for interoperability. I think you should mention this in the
> terminology section somewhere or not use RFC2119 language. 

Point taken. Will address this. Thanks!


> - You
> should define somewhere what you consider a "transient numeric
> identifier". - In the introduction and in the abstract you describe a
> problem with implementations (you refer to TCP) but the
> recommendations later aim for protocol authors. In many cases the
> authors of the specification and not the implementers. Do you believe
> that you have solved the problem?

Please see section 3: most of the times there are problems in the
implementations is because the advice in the specs is flawed, or because
the requirements are underspecified -- and hence the implementors have
no option other than figuring out things by themselves.

I can't think of a case of IDs where the specs did the right thing and
the implementors screwed up.




> More comments will follow...

Look forward to them!

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492