Re: [Add] TR: I-D Action: draft-btw-add-home-00.txt

[[e-mail]]

Hi Vittorio, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Add [mailto:[e-mail]] De la part de Vittorio Bertola
> Envoyé : mardi 10 mars 2020 11:00
> À : Stephen Farrell; ADD Mailing list
> Objet : Re: [Add] TR: I-D Action: draft-btw-add-home-00.txt
> 
> 
> 
> > Il 09/03/2020 14:05 Stephen Farrell <[e-mail]> ha
> scritto:
> >
> > But my main comment is that the home router that does
> > almost all DNS might not be provided by the ISP so any
> > discovery or similar protocol ought not make that
> > assumption. I recognise that that's a corner-case
> 
> Yes, it's an infrequent case, but I would not call it a corner case.
> At least in Europe, there is regulation that requires all ISPs to
> allow users to buy and deploy any CPE they like.

[Med] Agree (assuming the CPE is compliant with the technical specification to access the service published by providers).

Unmanaged CPEs can use the DNS configuration supplied by the network or the user can change that configuration to point to a public resolver. This is similar to what is already discussed in the draft:

   Some ISPs rely upon external resolvers (e.g., outsourced service or
   public resolvers); these ISPs provide their customers with the IP
   addresses of these resolvers.  These addresses are typically
   configured on CPEs using the same mechanisms listed above.  Likewise,
   users can modify the default DNS configuration of their CPEs (e.g.,
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   supplied by their ISP) to configure their favorite DNS servers.  This
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   document permits such deployments.

I updated the draft to make this explicit. You may check at: https://github.com/boucadair/draft-btw-add-home-network/blob/master/draft-btw-add-home-03.txt 

   3.  Sample Deployment Scenarios . . . . . . . . . . . . . . . . .   4
     3.1.  Managed CPEs  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Unmanaged CPEs  . . . . . . . . . . . . . . . . . . . . .   7

Do we need to say more? Thanks. 

 Also, it is
> relatively common, for smart users that couldn't get their ISP to do
> without the CPE, to deploy another router in front (LAN-side) of the
> CPE. This happens, for example, because the CPE has the appropriate
> fiber termination but the user's desired home router has not, but has
> other features that the user needs. So indeed these are use cases that
> have to be supported.

[Med] If the internal CPE does not embed a forwarder, that CPE "relays" the DNS information received from the ISP-supplied CPE or use the one set by the user. From a DNS standpoint, this is similar to the scenario above. 

If the internal CPE embeds a forwarder, the procedure we define for bootstrapping with an ISP DoH server + redirection to the forwarder on the CPE does not apply (Section 7 of the I-D). 

Considerations such as those discussed in Section 5.2 will need to be followed by the host/user. Assuming that setup, the internal CPE can use the options defined in the draft (if it supports them) to announce itself as a DoH resolver. Of course, if the user assigns a static address to the internal CPE, it can configure that @ directly on the hosts. Discovery is thus not relevant in such case. 

I'm afraid that we are getting into very specific setups. I suggest to leave this one out for the moment and focus on the scenarios that require less involvement from the user. 

What do you think?