Re: Roman Danyliw's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

[Fernando Gont <[e-mail]>]

Hi, Roman,

Thanks a lot for your feedback! It seems somehow I failed to respond to 
your message -- apologies for that! -- In-line....


On 20/10/20 17:48, Roman Danyliw via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Ben Kaduk’s DISCUSS position around the need for clarity on what
> “statistically different” means (per Section 3).
> 
> I also strongly concur with Ben’s guidance on the construction of the RID in
> Section 3.3.1

FWIW, both of these will hopefully be addressed by the next rev.



> ** Section 3.*.  The guidance uses the language of “deprecate”.  This to me
> would suggest some notion of state being kept where I know I’ve used an address
> before and I won’t use it again.  However, that doesn’t seem right here.

FWIW, "deprecate" is SLAAC terminology...




> ** Section 3.1.  Per “it must be difficult for an outside entity …”, what’s the
> rough thinking on the workload for “difficult” or is there more precise
> language.  I ask because Section 2.1

Not sure I'd be able to quantify that...



> ** Section 3.3. The subsections present two different algorithms.  Is there an
> MTI approach?

FWIW, what you need is a PRNG. The only reason for which we speficy two 
algorithms (as opposed to just random() ), is that the algorithm in 
Swction 3.3.2 might allow implementations to reuse code.



> ** Section 3.3.2.  This section suggests that use of SHA-256, but is there
> normative guidance on an MTI algorithm?

This document does not normatively require any specific algorithm for 
randomizing the IID.




> ** Section 3.3.2.  If the hash algorithm output length exceeds the needed
> identifier length, how should truncations be handled?

As per our discussion with Ben on a kind of related note, this is left 
as an implementation specific detail.



> ** Editorial
> -- Section 1.2.  Nit.  For consistency, s/on-link/on path/

In this case, that'd be incorrect. We really mean on-link, as "on the 
same link as the victim".

Thanks!

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