Subject: Re: [Dots] draft-ietf-dots-discovery: Valery's Comment in Montreal

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Aug 2019 11:54:59 +0300

Hi Med,

Hi Valery, 

You said during the meeting that you are not "happy" with the language used in section 4 (if I'm not mistaken). Are you referring to
this text: 

   All DOTS clients MUST support at least one of the three mechanisms

   below to determine a DOTS server list.  All DOTS clients SHOULD

   implement all three, or as many as are practical for any specific

   device, of these ways to discover DOTS servers, in order to

   facilitate the deployment of DOTS in large scale environments:

Can you please clarify your concern? 

yes, I meant this very text, but it was just an example of my concerns.

in general, I found using normative language in the document 

a bit chaotic and I think that sometimes it is used improperly. Note, that

the main purpose of using normative keywords is to help interoperability.

More concretely.

   All DOTS clients MUST support at least one of the three mechanisms

   below to determine a DOTS server list.  All DOTS clients SHOULD

   implement all three, or as many as are practical for any specific

   device, of these ways to discover DOTS servers, in order to

   facilitate the deployment of DOTS in large scale environments:

Why normative language is ever used here? Obviously, clients

must somehow know server's address to establish a connection, 

but is it essential for interoperability between DOTS implementations

how they got it? I don't think so. Even if you persuade me that 

it is essential, I still think that the language is used here 

improperly, since SHOULD is almost equal to MUST and 

you doesn't provide any excuses for not doing MUST.

If you use SHOULD, please describe when it's OK not to follow it.

But I still think that normative language is not needed here.

Another point. I'd rather recommend always provide a means

for local/manual configuration, as it us the easiest and most reliable way 

to configure server's address. All other mechanisms may fail if attack

is already in progress when the client is being configured...

   On hosts with more than one interface or address family (IPv4/v6),

   the DOTS server discovery procedure has to be performed for each

   combination of interface and address family.  A client MAY choose to

   perform the discovery procedure only for a desired interface/address

   combination if the client does not wish to discover a DOTS server for

   all combinations of interface and address family.

The same question - why MAY is used here instead of "may"?

   The above procedure MUST also be followed by a DOTS gateway.

   Likewise, this procedure MUST be followed by a DOTS server in the

   context of DOTS Signal Channel Call Home

   [I-D.ietf-dots-signal-call-home].

    The discovery method MUST be reiterated upon the following events:

The same question for MUST.

   1.  A DNS domain name is retrieved for each combination of interface

       and address family.  A DOTS client has to determine the domain in

       which it is located relying on dynamic means such as DHCP

       (Section 5) . Implementations MAY allow the user to specify a

       default name that is used, if no specific name has been

       configured.

The same question about normative language - why MAY instead of "may"?

And apart from using normative language: doesn't the text

   If the DHCP client receives more than one instance of

   OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use

   only the first instance of that option.

contradicts to the previous one

   To return more than one DOTS agents to the requesting DHCPv6 client,

   the DHCPv6 server returns multiple instances of

   OPTION_V6_DOTS_ADDRESS.

In other words, why to return several instances if only the first is always used?

Am I missing something?

Regards,

Valery.

 

Thank you. 

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 2 Aug 2019 11:53:21 +0000

Hi Valery,

Please see in line.

Cheers,
Med

De : Valery Smyslov [mailto:[email-masked]]
Envoyé : vendredi 2 août 2019 10:55
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : RE: draft-ietf-dots-discovery: Valery's Comment in Montreal

Hi Med,

Hi Valery,

You said during the meeting that you are not "happy" with the language used in section 4 (if I'm not mistaken). Are you referring to this text:

[Med] That's fair. Let's identify those and fix them.

More concretely.

how they got it?

[Med] It is for interoperability. Consider the example of a server provider which went with, e.g., provisioning S-NAPTR records while the client does only support DHCP options to discover a server. This client will never discover the IP address of its server.

I don't think so. Even if you persuade me that
it is essential, I still think that the language is used here
improperly, since SHOULD is almost equal to MUST and
you doesn't provide any excuses for not doing MUST.

[Med] We cannot go for a MUST because of the discussion in Section 3. For example, if we take into account how services are provisioned today to CPE, it does not make sense to mandate DNS-SD to be supported by a CPE.

[Med] Do you think text is still needed given the clarification above?

Another point. I'd rather recommend always provide a means
for local/manual configuration, as it us the easiest and most reliable way
to configure server's address.

[Med] That's fine for some deployments but manual configuration is not helpful for large scale deployment.

All other mechanisms may fail if attack
is already in progress when the client is being configured...

[Med] Manual configuration will also fail if the client does not have the "explicit" address to provide or if it has a name which will need to be resolved first.

The same question - why MAY is used here instead of "may"?
[Med] What is the issue with the use of "MAY" here?

The same question for MUST.
[Med] If this is not followed, the DOTS client may maintain a stale DOTS server...which is problematic.

The same question about normative language - why MAY instead of "may"?
[Med] Agree this one can be changed to "may" as this is about a configuration knob.

[Med] Good catch. Will be fixed. Thanks.

Regards,
Valery.

Thank you.

Cheers,
Med

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Aug 2019 15:30:44 +0300

Hi Med,

Hi Valery, 

Please see in line. 

Cheers,

Med

More concretely.

how they got it?

[Med] It is for interoperability. Consider the example of a server provider which went with, e.g., provisioning S-NAPTR records
while the client does only support DHCP options to discover a server. This client will never discover the IP address of its server. 

         OK, but you don't impose any requirement on how DOTS servers provision addresses, 

         so either clients must support all the methods or you still have

         the abovementioned situation to happen.

         And in this case manual configuration can help. Another reason to make it mandatory, no?

[Med] We cannot go for a MUST because of the discussion in Section 3. For example, if we take into account how services are
provisioned today to CPE, it does not make sense to mandate DNS-SD to be supported by a CPE.   

         Well, then can you be more concrete and clarify when it's OK for clients not to support all three methods.

         Without concrete excuses SHOULD is almost equal to MUST.

         Yes. The phrase "as are practical for any specific device" is too vague.

         Provide at least a couple examples.

         Sure. But from my understanding of DOTS use cases usually one company will 

         have few dots clients (unless it's a multinational corporation) and will

         be serviced by one (or few) ISP providing DOTS service.

         Not a big deal for IT department to configure them.

[Med] Manual configuration will also fail if the client does not have the "explicit" address to provide or if it has a name which
will need to be resolved first. 

         Yes. But at least it can be used to directly configure server address, without any network activity.

     I don't see a need for MAY here. "If the client doesn't wish..."

     is clearly a local policy decision, so why uppercase MAY?

[Med] If this is not followed, the DOTS client may maintain a stale DOTS server.which is problematic. 

         I think that lowercase must is OK here, since what you're actually saying 

         is that other kinds of DOTS clients (in fact client side of gateway

         and call home server) need to follow the case logic for discovering their

         respected servers.

         Regards,

         Valery.

Thank you. 

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 5 Aug 2019 11:54:07 +0000

Hi Valery,

Please see inline.

Cheers,
Med

De : Valery Smyslov [mailto:[email-masked]]
Envoyé : vendredi 2 août 2019 14:31
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : RE: draft-ietf-dots-discovery: Valery's Comment in Montreal

Hi Med,

Hi Valery,

Please see in line.

Cheers,
Med

More concretely.

[Med] This is supposed to be covered by "as many as are practical for any specific device". For example, a CPE device is likely to support a dynamic means such as DHCP and service resolution. For generic purpose devices, the language encourages the support of the three mechanisms.

         And in this case manual configuration can help. Another reason to make it mandatory, no?
[Med] Because this may not be practical for large scale deployments.

         Yes. The phrase "as are practical for any specific device" is too vague.
         Provide at least a couple examples.
[Med] OK, will add a pointer to Section 3 + examples.

[Med] Of course, but this is not the case for deployments making use of CPEs (embedding either a DOTS client or a Call Home DOTS server).

[Med] OK.

[Med] OK

         Regards,
         Valery.

Thank you.

Cheers,
Med