Re: [Dots] Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-14: (with DISCUSS and COMMENT)

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

Re-bonjour Med,

I have removed the parts where we agree. Additional comments are prefixed by EV>

Regards

-éric


-----Original Message-----
From: "[e-mail]" <[e-mail]>
Date: Wednesday, 4 November 2020 at 08:15
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Valery Smyslov <[e-mail]>, "[e-mail]" <[e-mail]>, "Bernie Volz (volz)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-14: (with DISCUSS and COMMENT)

    > -- Section 5.1.2 --
    > I fully second Zhen Cao's review: how will the IPv4-mapped IPv6
    > address(es) be used? They MUST not appear on the wire and there is a
    > DHCPv4 option to convey the DOTS information. Is it when DHCPv6 is
    > available, no DHCPv4, and only IPv4 connectivity to the DOTS server
    > ? If so, then please clarify the text.
    > 

    [Med] You got it. Added: " This is particularly useful in IPv4 service continuity deployments where only DHCPv6 is used."

EV> I am afraid that more text and explanations are required to clear my remaining DISCUSS even if your suggested modification is a big step forward


    > 
    > -- Section 4 --
    > While this section title is "Unified DOTS Discovery Procedure", I
    > read 3 different mechanisms so apparently conflicting with the
    > section title. Suggest to remove "unified" from the section title.

    [Med] It is "unified" in the sense that the different mechanisms as packaged to form one with an internal preference order. OK to remove it if it hurts.   

EV> yes, please remove the "unified" in the section title

    > 
    > Putting DHCP configuration under explicit configuration appears
    > weird to me as DHCP is rather dynamic and on the same level as DNSD.

    [Med] Not sure what is weird there. There two levels of explicit config as detailed in the text. 

EV> but my point is that DHCP is not really an explicit configuration rather a dynamic one. So, I do not see why the DHCP part is on the same level as static configuration in the 1st item in the list

    > 
    > May I suggest to move the sentence "DOTS clients will prefer
    > information received from the discovery methods in the order listed"
    > before the list? It is an important sentence IMHO.

    [Med] It is important in case the client supports many mechanisms and receives the information using various sources.

EV> sure but my point was to move this sentence *before* the enumeration due to its importance.

    > 
    > I wonder wheter the sentence "Expiry of a peer DOTS agent's
    > certificate currently in use." is correct... Should it be "agent
    > peer DOTS certificate" ?

    [Med] Would the "Expiry of the certificate of a peer DOTS agent" be better? To be honest, I'm not sure to get the issue with the initial wording. 


EV> it is indeed easier to read  / parse for a non-English reader like myself

    > 
    > -- Sections 5.1.3 and 5.2.3--
    > The part of the sentence "as distinguished by the presence of
    > multiple root labels" should be explained more as it is unclear.

    [Med] If multiple names were included, then each of these names will be terminating with a byte value of 0. We drafted the text with the assumption that the reader is familiar with Section 3.1 of RFC1035.

EV> sure about RFC 1035 ;-) but I wonder whether this part of the sentence is useful as the previous part " OPTION_V6_DOTS_RI contains more than one name" seems perfectly enough for me so reader may wonder about the part " as distinguished by the presence of multiple root labels"