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

[[e-mail]]

Re-,

Thanks, Eric. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Eric Vyncke (evyncke) [mailto:[e-mail]]
> Envoyé : mercredi 4 novembre 2020 11:49
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; The
> IESG <[e-mail]>
> Cc : [e-mail]; dots-
> [e-mail]; [e-mail]; Valery Smyslov <[e-mail]>;
> [e-mail]; Bernie Volz (volz) <[e-mail]>;
> [e-mail]
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-dots-server-
> discovery-14: (with DISCUSS and COMMENT)
> 
> 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]" <draft-ietf-dots-
> [e-mail]>, "[e-mail]" <dots-
> [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
> 

[Med] We can add some pointers rather than expanding the text. What about:  

"This is particularly useful in IPv4 service continuity deployments (e.g., [RFC6333]) where only DHCPv6 is used and DHCPv4-over-DHCPv6 [RFC7341] is not supported." 

> 
>     >
>     > -- 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

[Med] Done. 

> 
>     >
>     > 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.

[Med] I don’t get this one. An explicit config can be provided using static or dynamic mechanisms. DHCP falls into the second category. 

 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.

[Med] Done. Thanks.

> 
>     >
>     > 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
> 

[Med] Fixed. 

>     >
>     > -- 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"
> 

[Med] OK to remove it if you think this is obvious. 



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.