Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

[Vittorio Bertola <[e-mail]>]

>     Il 15/03/2021 16:09 Ben Schwartz <bemasc=[e-mail]> ha scritto:
> 
> 
>     Many have raised the difficulty of establishing an identity for the network and confirming that claims received by the client were produced by the network operator.  That is a challenge, but it is not my principal concern.  My main concern is that when we move from encoding what the network offers to what it "allows", we are discussing the IETF blessing certain Terms of Service as technical standards.
> 
>     Terms of Service are a thoroughly human, legal construct, not a mechanical handshake.  They represent an unbounded conceptual space that cannot be neatly quantized into an IANA registry.  Their interpretation is subject to social norms and judges' rulings.  Does "splitDNSAllowed: false" forbid the use of corporate VPN tunnels?  DNS entries already in cache?  mDNS? Using "dig" over SSH?  Alternate DNS servers if needed due to a medical emergency?  Namecoin?  Does ignoring this JSON blob constitute a violation of the US Computer Fraud and Abuse Act?  I don't want answers; I want to make sure that we don't have to ask these questions.
> 
>     Standardizing Terms of Service opens Pandora's Box.  The list of things that someone somewhere wants to tell a user not to do on their network is endless, and the IETF should not be in the business of judging which of these requests are appropriate.  (And we surely must judge, as some requests are clearly unconscionable.)
> 
>     As a practical matter, no such request can command IETF consensus, nor the consensus of this working group.  That's why the ADD charter goes to some length to remind us not to be distracted by them.
> 
As I understand, we can at least develop the mechanism for transport of such information. As for the meaning, an indication that the network uses its own resolvers for network management purposes and would like applications to never use any other resolver (exactly like Mozilla's canary domain mechanism, just with a different transport) is not ambiguous and does not require any policy discussion, as "never" means "never"; it is then up to the client to decide whether to take it literally, to take it with some freedom, or not to take it at all - and while doing this, to evaluate any legal and policy implication in the specific context.

I don't see the need to standardize the meaning of this signal up to the level of detail that you envisage, but if that were required, I agree that it should not happen here. That kind of standardization of terms of service usually happens either under the form of industry certification/classification schemes, or by agreeing on industry-wide guidelines, or by regulation.

> 
>     If you want to invest in improving network identity attribution, let's ensure that when users are reviewing the network's Terms of Service, they know exactly who the network operator is.
> 
That would also be useful.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] mailto:[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy