Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Buenos dias Fernando,

As you know, all my COMMENT points were non-blocking; therefore, I really appreciate your replies and your proposed changes (I agree with all of them + one preference for an alternative text) => this should improve the document quality!

See inline for EV> for any additional comments. I have removed all lines where we are in agreement.

Regards

-éric

-----Original Message-----
From: Fernando Gont <[e-mail]>
Date: Tuesday, 20 October 2020 at 18:18
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Ole Trøan <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

    Hello, Eric,

    Thanks a lot for your comments! In-line....

    On 20/10/20 10:49, Éric Vyncke via Datatracker wrote:
    [....]
 
   > I also appreciate the new section 3.7 where an admin can disable the mechanism.
    > Is there a reason why this document does not briefly compare its addresses with
    > RFC 7217 (stable address) ? It could be helpful for the reader.

    Such topic has been discussed at length in RFC7721.  That's why we've 
    referenced such document instead of trying to rehash the discussion.

EV> I agree that this document should not spend too much time in the comparison; but, when doing my IESG review I failed to see *where* in the document is the reference to this discussion in RFC 7721.

...%<....%<......  

  > 
    > Should link-local address generation also be considered here ? While the text
    > is clear about 'global', there is no clear indication that this document does
    > not apply to link-local addresses.

    The idea of this document was to revise RFC4941, addressing shortcomings 
    in said RFC. That's why the document remains the same wrt link-locals.

    That said, link-locals are a different problem space. e.g., there's not 
    much of a point in doing temporary addresses for link-locals if you 
    don't randomize link-layer addresses. For some technologies, randomizing 
    link layer addresses might force a network disconnect, etc.

EV> I still believe that it is worth mentioning even if only to avoid the EUI-64 based on MAC address for link-local (done in most OS AFAIK :-) ) but also keeping the same LLA when randomizing the MAC address is also kind of defeating the layer-2 privacy. We could talk for ever on this topic of course but my I kindly suggest to change the title of this document into " Temporary *Global* Address Extensions" (the abstract is clear about the coverage) and adding a few words on the importance of LLA ?

...%<....%<.....

    > -- Section 1.2 --
    > Should IPPIX collectors also be mentioned in the first bullet list ?

    WOuldn't that be somewhat included in bullet #1?

EV> up to you as authors, but for me the collector (== receive of IPFIX records) is not the monitor (== the node in bullet #1)


    > -- Section 3.6 --
    > Last paragraph "when an interface connects to a new (different) link, a new set
    > of temporary addresses MUST be generated immediately" seems to imply more than
    > 1 temporary address with the use of 'set' and the plural form. Unsure whether
    > it is the right behavior (esp if no RA-PIO are received yet).

    How about

    OLD:
        Finally, when an interface connects to a new (different) link, a new
        set of temporary addresses MUST be generated immediately for use on
        the new link.  If a device moves from one link to another, generating
        a new set of temporary addresses ensures that the device uses
        different randomized interface identifiers for the temporary
        addresses associated with the two links, making it more difficult to
        correlate addresses from the two different links as being from the
        same node.

    NEW:
        Finally, when an interface connects to a new (different) link,
        temporary addresses MUST be generated immediately for use on
        the new link.  If a device moves from one link to another, generating
        a new set of temporary addresses ensures that the device uses
        different randomized interface identifiers for the temporary
        addresses associated with the two links, making it more difficult to
        correlate addresses from the two different links as being from the
        same node.

    Xor, one might be more specific as in:

    NEW:
        Finally, when an interface connects to a new (different) link,
        existing temporary addresses for that interface MUST be
        eliminated, and new temporary addresses MUST be generated immediately
        for use on the new link, according to the algorithm in Section 3.4.
        If a device moves from one link to another, this will ensure that the
        device uses different randomized interface identifiers for the
        temporary addresses associated with the two links, making it more
        difficult to correlate addresses from the two different links as
        being from the same node.


    Thoughts?

EV> I prefer the 2nd alternative but the 1st one is also good IMHO

    > -- Section 6 --
    > If only this was not 'future work' but I agree, this is not up to this document
    > to specify such kernel API/implementation.

    Double-checking: No changes suggested here, right?