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

[<[e-mail]>]

Hi Valery,

Please see inline.

Cheers,
Med

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

Hi Med,

Hi Valery,

Please see in line.

Cheers,
Med

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?

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

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

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.

         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.

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

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

         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.

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.

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

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

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.

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

   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"?
[Med] What is the issue with the use of "MAY" here?

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

   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.
[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.
[Med] OK

         Regards,
         Valery.



Thank you.

Cheers,
Med